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Abstract 

As  defense  budgets  decrease  and  it  is  required  to  do  more  with  less,  the  Air  Force 
has  chosen  to  use  the  Malcolm  Baldrige  National  Quality  Award  (MBNQA)  as  the  basis 
for  implementing  quality  principles.  The  Air  Force  program  is  known  as  Quality  Air 
Force  (QAF),  and  the  criteria  are  referred  to  as  the  QAF  criteria  [DEPA95b].  At  about 
the  same  time  the  Department  of  the  Air  Force  implemented  QAF,  the  software  leaders  in 
the  Air  Force  adopted  the  Capability  Maturity  Model  for  Software  (CMM)  as  the  internal 
standard  for  Air  Force  software  organizations  [MOSE91].  Software  organizations 
strapped  with  both  sets  of  requirements  struggle  with  how  to  implement  both  models. 
Many  organizations  implement  redundant  programs  in  an  effort  to  satisfy  both.  This 
research  uses  signature  and  specification  matching  techniques  gleaned  from  the  software 
reuse  domain  to  integrate  the  CMM  and  QAF  criteria  into  a  single  set  of  requirements 


that  correlate  to  both  models. 


INTEGRATING  THE  CAPABILITY  MATURITY  MODEL 


FOR  SOFTWARE  AND  THE  QUALITY  AIR  FORCE  CRITERIA 


/.  Introduction 


LI  Background 

In  his  1993  book,  Decline  and  Fall  of  the  American  Programmer,  Ed  Yourdon 
predicts  the  American  programmer  will  “share  the  fate  of  the  dodo  bird”  by  the  end  of  the 
decade  [YOUR93].  Yourdon  goes  on  to  assert  that  international  competition  will  be  the 
downfall  of  American  software  companies  based  on  three  key  organizational  issues:  cost 
of  the  staff,  productivity  of  the  staff,  and  quality  of  the  systems  developed  [YOUR93]. 
To  avoid  Yourdon’s  predictions  of  doom,  many  American  software  companies  have 
turned  to  the  concepts  of  Total  Quality  Management  (TQM)  as  the  basis  for  addressing 
two  of  the  three  key  issues— increasing  productivity  of  the  staff  and  improving  quality  of 
the  systems  developed. 

The  application  of  TQM  principles  comes  in  many  forms,  such  as  the  Malcolm 
Baldrige  National  Quality  Award  (MBNQA),  the  Capability  Maturity  Model  for  Software 
(CMM),  and  the  International  Standards  Organization  (ISO)  9000  standards  to  name  a 


few.  The  various  forms  of  TQM  have  many  commonalties,  but  often  differ  in  scope, 
depth,  breadth,  and  applicability;  therefore,  many  organizations  use  a  combination  of  two 
or  more  approaches  in  their  quality  programs  [FALL93].  To  combine  multiple 
approaches  can  be  quite  difficult;  it  is  essential  to  comprehensively  understand  each  of 
the  approaches  used,  and  how  the  approaches  interact. 

Air  Force  software  organizations  have  found  out  just  how  difficult  it  can  be.  The 
Air  Force  adopted  the  MBNQA  criteria  as  its  approach  to  implementing  TQM  principles. 
The  criteria  are  the  cornerstone  of  the  Air  Force  quality  program  known  as  Quality  Air 
Force  (QAF).  All  Air  Force  organizations,  including  software  organizations,  are  required 
to  implement  assessment  and  improvement  programs  based  on  QAF  criteria  [DEPA95a]. 
Air  Force  software  organizations  have  an  additional  requirement.  In  addition  to 
assessments  and  improvements  based  on  the  QAF  criteria,  software  organizations  must 
also  implement  assessments  and  improvements  based  on  the  CMM  [MOSE91]. 

Multiple  assessments  and  improvement  efforts  can  be  very  expensive,  especially  in 
terms  of  time  and  human  resources.  The  assessments  for  either  model  involve  a  great 
deal  of  training,  planning,  and  preparation.  Both  types  of  assessment  include  multiple 
interviews  with  a  significant  number  of  members  in  the  organization.  In  fact,  for  the 
QAF  assessment  at  the  Air  Force  Test  and  Evaluation  Center,  nearly  one  fifth  of  its  800 
employees  were  interviewed  in  the  validation  phase,  which  is  only  one  portion  of  the 
assessment  process  [REED94].  CMM  assessments  are  no  different.  Current  guidance  on 
CMM-based  assessments  describes  the  typical  assessment  as  involving  a  team  leader, 
along  with  eight  team  members,  interviewing  four  project  leaders  and  40  functional  area 
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representatives,  and  expending  about  200  person-days  of  effort  [DUNA96].  Moreover, 
the  assessment  is  only  a  small  part  of  the  overall  cost  of  improvement  programs.  The 
Software  Engineering  Institute  recommends  investing  one  to  three  percent  of 
development  costs  in  CMM  improvement  activities  [NEXT92].  In  regards  to  the  QAF 
criteria,  commanders  are  not  only  required  to  perform  assessments,  but  furthermore 
required  to  provide  enough  resources  to  implement  the  criteria  [DEPA95b]. 

1.2  Problem 

The  QAF  criteria  and  the  CMM  are  meant  to  spur  process  improvements  with  the 
ultimate  goal  of  increased  productivity,  quality,  and  customer  satisfaction.  Nevertheless, 
attempts  to  combine  the  two  approaches  often  produce  the  opposite  effects  in  many  Air 
Force  software  organizations.  These  organizations  have  failed  to  integrate  the  CMM  and 
the  QAF  criteria  into  a  single,  coherent  improvement  strategy.  Consequently,  as  stated  by 
Mara  of  the  Air  Force  Standard  Systems  Groups,  “Air  Force  software  units  spend 
valuable  resources  attempting  to  implement  parallel  improvement  initiatives” 
[MARA96]-one  based  on  the  CMM  and  the  other  based  on  the  QAF  criteria.  Inevitably, 
parallel  initiatives  result  in  redundant  objectives,  redundant  assessments,  and  redundant 
infrastructures.  The  Software  Management  Division  of  the  Air  Force  Communications 
Agency,  the  office  of  primary  responsibility  for  assessing  software  maturity,  receives 
frequent  requests  for  a  strategy  to  integrate  the  two  improvement  approaches.  With 
redundancy  in  assessments  and  improvement  programs.  Air  Force  software  organizations 
waste  scarce  resources. 


3 


Problem  Statement: 


Air  Force  software  organizations  are  unable  to  integrate  the  CMM  with  the  QAF 
criteria,  leading  to  parallel  improvement  initiatives,  and  resulting  in  the  wasted  resources. 

1.3  Research  Objectives 

The  goal  of  this  research  is  to  demonstrate  the  use  of  signature  and  specification 
matching  (as  described  in  Section  3.4.1  and  3.4.2,  respectively)  to  integrate  the  process 
requirements  imposed  by  the  Capability  Maturity  Model  for  Software  and  the  Quality  Air 
Force  criteria.  The  following  objectives  support  the  achievement  of  this  goal: 

1 .  Specify  the  process  requirements  stipulated  by  the  CMM. 

2.  Specify  the  process  requirements  stipulated  by  the  QAF  Criteria. 

3.  Integrate  requirements  from  each  model  into  one  set  of  consistent  requirements. 

4.  Demonstrate  the  use  of  signature  matching  to  integrate  requirements. 

5.  Demonstrate  the  use  of  specification  matching  to  integrate  requirements. 

6.  Demonstrate  the  use  of  the  integrated  set  of  requirements  by  applying  it  to  an 
organization  process  description,  specifically  the  Standard  Systems  Group’s 
System  Engineering  Process  (SEP). 

7.  Illustrate  the  consistency  and  compatibility  of  the  models. 
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1.4  Approach 


The  following  approach  is  used  to  meet  the  stated  objectives  and  attain  the  overall 
goal  of  the  research: 

1.  Decompose  the  CMM  and  QAF  Criteria  into  low  level  process  requirements  - 
Each  model  is  structurally  partitioned  into  categories  of  logically-related 
process  and  sub-process  requirements.  Taking  advantage  of  this  structure,  the 
requirements  are  further  decomposed  until  each  requirement  specifies  only  one 
output,  or  a  small  number  of  strongly-connected  outputs.  Decomposing  the 
models  to  this  point  is  essential  to  fully  understand  each  requirement  with  an 
aim  towards  formal  specification  of  each  requirement,  if  needed.  (Supports 
Objectives  1  and  2.) 

2.  Log  process  requirements  into  a  framework  for  process  documentation  -  The 
primary  purpose  of  the  framework  is  to  communicate  process  requirements  to 
the  sponsoring  organization,  as  well  as  other  process  experts.  A  secondary 
purpose  is  to  manage  the  many  requirements.  (Supports  Objectives  6  and  7.) 

3.  Specify  signatures  of  each  process  requirement  -  Signatures  are  identified  in 
conjunction  with  the  decomposition  in  Step  1.  It  is  the  linchpin  of  this 
approach.  (Supports  Objectives  3  and  4.) 

4.  Integrate  the  requirements  using  signature  matching  -  The  signature  of  each 
individual  requirement  is  compared  to  the  signature  of  all  other  requirements 
(including  those  from  the  same  model)  to  determine  a  candidate  list  of 
redundant  requirements.  Contextual  information  is  re-introduced  to  determine 
if  any  of  the  candidates  can  be  definitively  identified  as  matches.  (Supports 
Objective  4.) 

5.  Specify  appropriate  requirements  in  the  Z  specification  language  -  For  those 
requirements  not  discernible  as  matches  or  non-matches  using  signature 
matching  and  contextual  information,  specification  matching  is  used  as  the  final 
discriminator.  The  requirements  are  specified  in  Z  and  then  compared  using 
specification  matching.  Using  English,  the  requirements  can  only  be  compared 
in  a  conceptual,  or  notional  manner.  A  formal  language,  on  the  other  hand, 
provides  the  power  of  mathematically  comparing  inputs,  outputs,  and  behaviors. 
(Supports  Objective  5.) 
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6.  Integrate  the  remaining  requirements  using  specification  matching  -  The 
behavioral  specification  for  each  requirement  compared  to  other  remaining 
requirements  to  definitively  establish  the  relationship  between  the  two.  An 
exact  match  indicates  redundancy,  thus  one  of  the  requirements  is  eliminated. 
(Supports  Objective  5.) 

7.  Verify  the  integrated  set  of  requirements  -  Each  requirement  in  the  integrated 
set  of  requirements  is  correlated  back  to  the  model  from  which  it  originated. 
The  set  is  checked  for  completeness  by  composing  requirements  (i.e.,  the 
processes  they  represent)  from  the  final  set  into  process  descriptions.  This  step 
also  provides  information  on  the  compatibility  of  the  two  models.  (Supports 
Objective  3  and  7.) 

8.  Apply  the  integrated  set  of  requirements  to  a  part  of  the  sponsor’s 
organizational  process  description  -  A  part  of  the  Standard  System  Group’s 
(SSG)  Systems  Engineering  Process  (SEP)  is  evaluated  against  the  integrated 
set  of  requirements.  Unmet  requirements  are  identified  and  noted  for  the 
sponsor.  The  application  step  also  acts  as  a  validation  for  the  integrated 
requirements.  The  process  description  is  reviewed  to  identify  processes  or  sub¬ 
processes  with  no  corresponding  requirement.  The  models  are  checked  to 
determine  if  a  requirement  was  lost  in  the  approach  or  not  provided.  (Supports 
Objective  6.) 


1.5  Assumptions 

1.5.1  Pre-condition  and  Post-condition.  The  first  assumption  is  that  both  the  CMM 
and  QAF  criteria  may  be  specified  in  a  pre-condition,  post-condition  form.  While  the 
CMM  is  largely  structured  in  this  form,  the  QAF  criteria  are  not  and  may  be  much  more 
difficult  to  specify  in  this  form.  This  assumption  is  crucial  to  comparing  requirements 
using  specification  matching. 

1.5.2  No  Conflicts  between  the  Models.  Secondly,  assume  there  are  no  outright 
conflicts  between  the  models,  e.g.,  the  CMM  requires  A  and  the  QAF  criteria  requires 
-lA.  This  is  a  reasonable  assumption  since  both  models  support  the  same  principles  and 
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are  used  together  by  many  organizations.  If  such  conflicts  do  occur,  the  organization 
must  simply  make  a  decision  on  which  method  benefits  it  most. 

1.5.3  Key  Processes  Versus  All  Processes.  Neither  model  describes  every  process 
an  organization  needs  or  uses.  The  QAF  criteria,  although  described  as  a  “comprehensive 
set  of  results-oriented  requirements”  [DEPA95c],  primarily  discusses  meta-processes,  or 
processes  to  manage  processes.  The  criteria  do  not  attempt  to  describe  each 
organization’s  production  processes.  The  CMM  describes  a  software  production  process, 
along  with  meta-processes,  but  does  not  specify  every  process  needed  by  an  organization. 
For  instance,  the  CMM  barely  addresses  any  human  resource  issues  or  processes  outside 
of  training. 

Basically,,  both  models  are  descriptive  in  nature;  they  describe  what  is  to  be  done, 
but  not  how.  In  many  cases,  how  a  process  is  implemented  involves  many  other 
processes  not  identified  by  either  model.  An  example  is  data  collection.  Both  models 
require  data  collection  and  give  guidance  on  the  type  of  data  to  collect,  but  neither 
describes  the  process  to  actually  collect,  store,  or  retrieve  the  data.  This  approach  does 
not  attempt  to  extend  beyond  the  scope  or  depth  already  contained  in  the  CMM  and  QAF 
criteria. 

1.5.4  Goals  in  the  CMM  Are  Accomplished  by  Activities  Performed.  The  structure 
of  the  CMM  contains  goals  for  each  Key  Process  Area.  This  approach  assumes  that 
performing  all  the  practices  in  the  Activities  Performed  and  Other  Common  Features 
satisfies  the  goals.  The  goals  are  not  explicitly  addressed  as  process  requirements. 
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1.6  Scope 


This  research  addresses  how  to  integrate  two  sets  of  requirements,  namely  the  CMM 
and  QAF  Criteria,  based  on  signature  matching  and  specification  matching.  It  does  not 
include  how  to  conduct  assessments  based  on  either  model,  nor  how  to  implement  the 
requirements  of  either  model.  Neither  does  it  address  the  applicability,  nor  the 
effectiveness  of  using  either  model  in  the  Air  Force.  Likewise,  this  research  does  not 
advocate  the  use  of  one  model  over  the  other,  but  rather  views  them  as  complementary. 
Finally,  this  research  does  not  include  a  method  for  converting  scores  from  one 
assessment  method  to  the  other. 

1.7  Overview 

The  remainder  of  this  document  details  the  research  outlined  above.  Chapter  n 
discusses  the  literature  reviewed  in  support  of  the  research.  It  consists  of  sections  on 
requirements  analysis,  process,  software  reuse,  and  the  two  models  used  in  the  research. 
Chapter  HI  describes  the  approach  followed  in  the  research.  It  is  divided  into  sections  for 
each  of  the  major  steps  in  the  approach.  Chapter  IV  analyzes  the  approach  and  gives 
intermediate  and  final  results.  Chapter  V  addresses  verifying  results  and  applying  them  to 
a  process  description.  The  final  chapter.  Chapter  VI  discusses  conclusions  drawn  from 
the  research  effort,  how  the  approach  can  be  used  in  other  areas,  and  suggests  some 
avenues  for  further  research. 
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//.  Literature  Review 


2. 1  Introduction 

The  overall  goal  of  this  research  is  to  demonstrate  the  use  of  signature  matching  and 
specification  matching  to  integrate  process  requirements  imposed  by  the  Capability 
Maturity  Model  for  Software  and  the  Quality  Air  Force  criteria.  Several  areas  are 
reviewed  to  support  this  research.  Section  2.2  contains  a  general  discussion  of 
requirements  analysis,  and  includes  formal  methods,  with  an  introduction  to  the  Z 
language.  The  next  section  covers  process;  it  consists  of  discussions  on  the  software 
process,  process  modeling,  and  process  improvement.  Following  that.  Section  2.4  briefly 
discusses  the  current  state  of  software  reuse,  along  with  two  related  methods  for 
retrieving  reusable  components.  Finally,  Sections  2.5  and  2.6  preview  the  QAF  Criteria 
and  the  CMM,  respectively. 

2.2  Requirements  Analysis 

The  purpose  of  the  requirements  phase  of  the  software  lifecycle  is  to  sufficiently 
describe  the  behavior  of  the  system  by  specifying  the  requirements  the  software  system 
must  meet.  The  requirements  are  meant  to  describe  what  the  system  does,  without 
detailing  how  the  system  will  do  it  [DAVI90].  The  what  versus  how  is  often  a  matter  of 
perspective,  but  a  commonly  accepted  view  for  software  is  the  what  describes  the 
problem  domain  and  restricts  the  solution  space.  The  how  begins  the  design  phase  which 
chooses  a  particular  solution  to  implement.  The  design  phase  begins  with  a  description  of 
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architectural  components,  major  functions,  and  relationships,  which  are  successively 
refined  into  the  detailed  design  and  code  for  the  system  [RUMB91]. 

Describing  the  problem  domain  involves  activities  such  as  interviewing, 
brainstorming,  flowcharting,  diagramming,  and  modeling.  The  objective  is  to  fully 
understand  the  problem  at  hand  and  identify  any  constraints  on  the  solution.  Managing 
the  data  and  information  gathered  and  created  is  a  key  challenge  to  this  part  of  the 
analysis  phase.  How  well  the  data  and  information  are  managed  has  a  direct  bearing  on 
the  success  of  the  next  part  of  the  analysis  phase.  In  this  part,  there  is  a  shift  from  the 
problem  domain  to  the  solution  space,  i.e.,  the  what  of  the  product  is  described.  The  goal 
is  to  completely  specify  the  behavior  of  possible  systems  which  solve  the  problem. 
Concisely  documenting  system  behavior,  resolving  conflicts,  and  eliminating 
inconsistencies  are  the  key  challenges  to  this  part  of  the  analysis  phase  [DAVI90].  The 
analysis  phase  culminates  in  a  requirements  document. 

2.2.1  Informal  Methods.  There  are  a  variety  of  methods  and  methodologies  to 
describe  the  what  and  the  how  of  the  software  system.  Informal  methods  are  the  most 
common.  Informal  methods  include  the  use  of  natural  language,  flowcharts,  data  flow 
diagrams,  entity-relationship  diagrams,  and  control  charts  to  name  a  few.  Other  informal 
methods  such  as  Structured  Analysis  and  Design  Technique  (SADT)  and  Object 
Modeling  Technique  (OMT)  add  structure  and  rigor  to  requirements  analysis.  Informal 
methods  can  be  quite  effective,  but  suffer  from  some  limitations.  One  limitation  is 
difficulty  teaching  the  methods.  Because  informal  methods  often  rely  on  art  and 
experience  rather  than  science  and  theory,  it  is  hard  to  convey  the  knowledge  to  others. 
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Another  limitation  concerns  automation.  Automation,  when  used  correctly,  can 
significantly  increase  productivity  and  quality,  but  informal  methods  rely  heavily  on  the 
human  component,  and  are  thus  hard  to  automate.  An  additional  limitation  is  the  chance 
for  error.  Informal  methods  increase  the  possibility  of  misinterpreting  or  misstating 
requirements.  More  often  than  not,  such  errors  promulgate  through  the  design  phase  and 
into  code.  This  is  especially  significant  since  it  may  be  as  much  as  100  times  more  costly 
to  fix  an  error  in  the  maintenance  phase  than  in  the  requirements  phase  [DAVI90, 
HART95]. 

2.2.2  Formal  Methods.  In  an  attempt  to  alleviate  some  of  the  limitations  of 
informal  analysis  methods,  formal  methods  were  developed.  Formal  methods,  unlike  the 
informal  ones  mentioned  above,  are  based  in  mathematics.  The  mathematics  are  typically 
expressed  in  the  form  of  a  formal  specification  language.  Specification  languages  may  be 
classified  as  property-oriented  or  model-oriented.  Property-oriented  specification 
languages  indirectly  describe  system  behavior  in  the  form  of  axioms  the  system  must 
satisfy.  Model-oriented  specification  languages  directly  describe  system  behavior  in  the 
form  of  functions,  relations,  tuples,  sets  and  sequences.  Some  examples  of  property- 
oriented  specification  languages  are  Larch,  Anna,  and  OBJ.  Some  examples  of  model- 
oriented  specification  languages  are  VDM,  state  machines,  and  Z  [MARC94]. 

2.2.3  Z  Specification  Language.  Z  is  a  model-oriented  specification  language,  hut  it 
is  also  used  for  property-oriented  specifications.  Z  specifications  consist  of  a  tormal 
notation  based  on  logic  and  set  theory  and  an  informal  part  written  in  natural  language. 
Natural  language  is  used  for  explanation  and  serves  as  a  bridge  between  the  real  um  ld 
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and  the  mathematics  of  the  formal  notation.  The  formal  notation  is  organized  by  means 
of  a  schema.  A  schema  is  a  collection  of  objects  and  axioms  relating  the  objects  to  each 
other.  Schemas  may  be  combined  through  the  use  of  schema  calculus,  providing  a  wealth 
of  expressive  power  [MARC94,  POTT91,  SPIV88]. 

2.3  Process 

This  section  provides  an  overview  of  process,  specifically  the  software  process  and 
how  it  relates  to  the  business  process.  It  also  surveys  methods  for  understanding  and 
improving  the  software  process. 

2.3.1  Software  Process.  The  CMM  defines  the  software  process  as  a  “set  of 
activities,  methods,  practices,  and  transformations  that  people  use  to  develop  and 
maintain  software  and  the  associated  products”  [PAUL93b].  This  definition  does  not 
mention  the  management  infrastructure  and  support  processes  necessary  to  successfully 
develop  software  products.  The  management  and  support  structures  are  often  referred  to 
as  the  business  process.  The  business  process  has  been  the  subject  of  great  interest  in 
recent  years,  as  evidenced  by  the  number  of  papers,  books,  and  World  Wide  Web  sites 
addressing  business  process  engineering  and  re-engineering.  The  business  process  is  also 
of  interest  to  the  software  community,  especially  how  it  relates  to  the  software  process. 

The  software  community  has  begun  to  appreciate  the  many  similarities  between  the 
software  process  and  business  process  [BOYD94].  In  a  panel  discussion  titled  “Are 
Software  Processes  Business  Processes  Too?”  at  the  Third  International  Conference  on 
the  Software  Process,  Henderson  proposes  a  simple  view  of  the  relationship.  He  views 
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the  software  process  as  simply  a  special  case  of  the  business  process.  He  defines  the 
business  process  as  “what  the  business  does  to  make  a  profit”  [HEND94].  In  the  case  of 
a  business  that  produces  software  to  make  a  profit,  the  software  process  is  a  business 
process.  Others  on  the  panel,  including  Boyd  [BOYD94],  Scacchi  [SCAC94],  and 
Thomas  [THOM94],  share  similar  views  to  that  of  Henderson,  namely  that  the  software 
process  and  business  process  are  closely  related  and  tightly  coupled  to  one  another. 
Regardless  of  the  particular  viewpoint  of  how  they  are  related,  most  would  agree  the 
critical  process  issues  in  both  the  software  and  business  arenas  are  to  define  the  process, 
manage  it,  and  improve  it.  Processes  to  perform  these  functions  are  called  meta¬ 
processes  [DOWS94]. 

2.3.2  Process  Modeling.  To  effectively  manage  and  improve  processes, 
organizations  must  first  understand  those  processes  [HUMP89].  An  effective  method  for 
understanding  a  process  is  process  modeling.  Process  modeling  not  only  contributes  to 
understanding  processes  currently  in  use  in  an  organization,  but  also  facilitates 
understanding  what  constitutes  good,  effective  processes  in  general  [DOWS94]. 

The  notion  of  process  modeling  stems  from  Osterweil’s  1987  paper  “Software 
Processes  are  Software  Too,”  presented  at  the  9th  International  Conference  on  Software 
Engineering  [OSTE87].  In  this  seminal  work  in  the  process  field,  Osterweil  makes  a 
strong  case  for  considering  software  processes  the  same  as  a  software  programs,  i.e., 
using  the  same  “techniques  and  formalisms”  to  describe  them.  He  introduces  the  idea  of 
process  programming,  or  rigorously  describing  the  software  process  much  in  the  same 
way  a  software  program  is  rigorously  described  using  a  programming  language 
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[OSTE87].  Process  programming  is  more  commonly  known  today  as  process  definition 
or  process  modeling. 

There  are  several  taxonomies  for  process  models  and  associated  techniques.  Process 
models  may  be  descriptive  or  active.  Descriptive  models  describe  what  steps  or  activities 
must  be  accomplished,  but  do  not  address  how  they  are  accomplished.  Active  models, 
often  called  process  enactment  systems,  prescribe  actions,  how  to  do  them,  and  usually 
aid  the  software  developer  in  accomplishing  the  task  [SNOW96].  Another  delineation 
between  modeling  techniques  is  static  versus  dynamic.  Static  models  textually  or 
graphically  describe  a  process,  while  dynamic  models  are  executable  in  some  way.  Static 
models  are  useful  for  understanding  processes  at  a  high  level,  but  often  do  not  provide  the 
deeper  understanding  obtained  by  using  dynamic  models  [BARG94].  These  taxonomies 
may  be  used  together  to  further  characterize  process  models.  A  descriptive  model  may  be 
static  or  dynamic,  and  an  active  model  may  be  static  or  dynamic.  Most  actives  models 
are  dynamic,  as  with  Computer  Aided  Software  Engineering  (CASE)  tools. 

The  selection  of  which  technique  or  type  of  model  to  use  depends  on  the  goals  of  the 
modeling  effort.  Descriptive  models  are  frequently  used  for  determining  how  a  particular 
process  behaves  under  various  conditions.  For  this  purpose,  the  model  is  normally 
executable,  or  dynamic.  Thus,  the  modeler  is  able  to  make  experimental  changes  to  the 
input  conditions  or  the  process  model  itself  to  identify  opportunities  for  improvement. 
As  mentioned  above,  active  models  are  often  used  to  enact,  or  help  perform,  the  process. 
These  active  models  must  include  specific  information  on  the  structure  of  the  process, 
agents  in  the  process,  and  artifacts  produced  or  consumed  by  the  process.  Because  of  the 
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amount  of  detail  involved,  these  type  models  are  often  called  process  definitions 
[DOWS93]. 

2.3.3  Process  Improvement.  In  the  past  decade,  software  organizations  around  the 
country  and  around  the  world  have  searched  for  the  engine  to  pull  them  out  of  the 
software  crisis.  Many  have  hoped  for  a  “silver  bullet”  in  the  form  of  a  technological 
advance  which  would  slay  the  software  werewolf  [BR0087].  Humphrey  notes  this  is  not 
only  wrong  thinking,  but  dangerous  thinking.  Technology  is  limited  by  the  process  it 
supports.  Poor  process  management  brought  about  by  an  insufficient  knowledge  of  the 
process  severely  degrades  productivity  and  quality  [HUMP89].  Productivity  and  quality 
gains  are  realized  by  a  firm  understanding  and  improvement  of  the  underlying  process. 
In  the  late  1980s,  the  software  industry  started  to  adopt  Humphrey’s  emphasis  on  the 
process  as  the  leverage  point  for  improving  productivity  and  quality  [NASE94]. 

As  mentioned  above,  the  objective  of  defining  the  process  is  to  understand  and 
improve  it,  but  process  improvement  is  not  the  end  itself.  Process  improvement  efforts 
must  be  firmly  linked  to  the  business  goals  of  the  organization.  Business  goals  provide  a 
context  for  improvement  efforts  [BOYC95].  For  example,  a  process  improvement  effort 
may  support  a  goal  to  increase  productivity  by  eliminating  steps  in  a  process  or  otherwise 
decreasing  execution  time.  When  aligned  with  business  goals,  process  improvement  can 
be  quite  successful  as  evidenced  by  Hughes  Aircraft  [HUMP91],  Raytheon  Equipment 
Division  [DION90],  and  Oklahoma  City  Air  Logistics  Center  [BUTL95]. 
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2.4  Software  Reuse 


Software  reuse  is  a  major  player  in  the  software  development  field.  By  reusing  code 
alone,  an  organization  can  increase  productivity  and  quality.  Productivity  increases 
because  portions  of  a  system  are  already  analyzed,  designed,  and  developed.  Quality 
increases  because  reused  code  is  managed  more  tightly  and  tested  with  each  new  use 
[YOUR93].  Although  the  gains  from  code  reuse  may  be  significant,  it  is  even  more 
lucrative  to  extend  reuse  beyond  code  to  requirements,  designs,  tests,  plans,  architectures, 
and  processes  [BASI94].  Yourdon  points  out  that  coding  comprises  only  10-15%  of  the 
resources  for  a  typical  project,  yet  most  of  the  efforts  in  reuse  have  focused  on  reusing 
code.  This  narrow  focus,  however,  has  begun  to  widen  [YOUR93]. 

Despite  the  potential  pay  back,  reuse  (including  code  reuse)  is  far  from  prolific  in 
the  software  coihmunity  due  to  several  factors.  The  factors  hindering  the  application  of 
software  reuse  in  most  organizations  can  be  categorized  as  managerial,  psychological,  or 
technical.  First  of  all,  management  must  be  committed  to  reuse  before  it  will  be  effective 
and  productive.  Like  any  other  major  organizational  direction,  commitment  means  a 
long-term  investment  in  the  resources,  tools,  and  training  necessary  for  it  to  work. 
Management  must  address  internal  issues  such  as  measurement  of  reuse  products  and 
processes,  as  well  as  explore  external  issues  such  as  legalities  and  marketing  [ZAND951. 
Psychological  factors  also  inhibit  reuse.  These  factors  primarily  affect  the  programmers 
who  are  responsible  for  implementing  reuse.  Programmers  take  pride  in  creating  their 
own  solutions  to  problems,  and  do  not  fully  trust  the  solutions  of  others.  Combine  these 
with  a  lack  of  incentive  for  reuse  and  a  lack  of  understanding  of  reuse  and  it  makes  ttie 
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programmer’s  choice  to  apply  reuse  a  difficult  one  to  make  [YOUR93].  Although 
managerial  and  psychological  factors  are  recognized  as  important,  most  of  the  research 
addresses  the  technical  factors  limiting  reuse.  Technical  factors  include  creating, 
classifying,  storing,  retrieving,  verifying,  and  modifying  components  of  a  library.  The 
major  impediment  is  efficiently  retrieving  a  component  that  meets  current  needs.  Despite 
the  amount  of  research  in  this  area,  “current  techniques  to  represent  and  manage  software 
components  are  not  sufficient,”  according  to  Jeng  [JENG95].  Jeng  and  Cheng’s  approach 
relies  on  formal  methods  to  specify  components  and  mathematically  determine  matches 
with  requirements  [JENG95].  Zaremski  and  Wing  propose  a  similar  method  to  match 
signatures  and  specifications[ZARE95a,  ZARE95b]. 

2.4.1  Signature  Matching.  Signature  matching  is  a  simple  method  for  identifying 
and  retrieving  components  from  a  reuse  repository  [ZARE95a].  Identification  and 
retrieval  must  be  done  effectively  and  economically  for  reuse  to  be  profitable.  Signature 
matching  provides  the  economical  means  of  identifying  and  retrieving  candidate 
components  from  a  repository  based  on  match  predicate  and  query.  Zaremski  and  Wing 
define  the  general  form  of  signature  matching  as  [ZARE95a]; 

Signature  Match(q,M,C)  =  {c  e  C:  M(c,q)} 

This  says  given  a  query  q,  a  match  predicate  M,  and  a  library  of  components  C,  Signature 
Match  returns  a  set  of  components  such  that  each  component  c  is  in  the  library  and 
matches  the  query  q  based  on  the  predicate  M,  i.e.,  c  and  q  satisfy  M  [ZARE95a]. 

Signature  matching  can  be  applied  to  functions  or  modules.  Modules  are  essentially 
a  collection  of  functions  which  operate  on  an  abstract  data  type.  Signature  matching  on 
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functions  is  essentially  type  matching  on  inputs  and  outputs.  The  match  predicates  for 
functions  can  take  on  several  forms  including  Exact  Match,  Generalized  Match,  and 
Specialized  Match  [ZARE95a].  Exact  Match  means  query  and  component  match  exactly. 
For  example,  the  signature  of  a  component  that  concatenates  two  strings  might  look  like: 

Catenate:  string,  string - >  string 

For  Exact  Match  to  find  and  return  this  component,  the  query  would  also  have  to  be: 

qj  =  string,  string - >  string 

Generalized  Match  finds  library  components  that  are  generalized  forms  of  the  query.  Re¬ 
using  qi  as  the  query.  Generalized  Match  would  return  components  that  require  two 
inputs  of  the  same  type  and  return  that  type.  The  signature  of  such  components  is: 

ci:  X,  X - >  X 

Specialized  Match  means  the  library  component  is  a  specialized  form  of  the  query.  In  this 
case,  C|  becomes  the  query,  qi: 

q2  =  X,X - ^  X 

This  query  would  return  Catenate,  in  addition  to  any  other  component  with  a  signature  of 
this  form.  For  example,  the  following  components  would  also  be  returned: 

Addint:  int,  int - >  int 

MergeFiles:  file,  file - >  file 

Signature  matching  on  modules  involves  matching  types  for  the  set  of  user-defined 
types  used  in  the  module,  along  with  matching  the  function  types  for  all  functions  in  the 
module.  Exact  Match  is  as  expected;  all  user-defined  types  must  match,  as  well  as  all 
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function  types  for  each  function  in  the  component  and  each  function  in  the  query.  The 
mapping  of  functions  in  the  query  to  functions  in  the  component  is  one-to-one  and  onto. 
One-to-one  means  that  for  each  function  in  the  query  there  is  only  one  function  in  the 
component  that  matches  it.  Onto  means  all  the  functions  in  the  component  are  matched 
to  functions  in  the  query.  Partial  Match  entails  using  queries  that  specify  only  a  subset  of 
the  functions  contained  in  the  library  module.  The  mapping  from  query  function  to 
component  function  does  not  need  to  be  onto  [ZARE95a]. 

2.4.2  Specification  Matching.  Specification  matching  is  essentially  the  same 
concept  as  signature  matching.  The  purpose  is  to  identify  and  retrieve  components  from  a 
reuse  repository.  The  difference  is  the  depth  at  which  components  are  matched.  In 
signature  matching  only  the  input/output  types  are  compared  to  determine  a  match.  This 
technique  provides  a  good  filter  for  identifying  candidate  components,  but  may  lead  to 
some  surprises.  To  illustrate  this  point,  consider  the  signature  of  two  possible  string 
operations.  Catenate  and  Replace: 

Catenate:  string,  string - >  string 

Replace:  string,  string - >  string 

The  two  have  the  same  signature  and  would  match  the  same  queries;  however,  the  two 
behave  very  differently.  For  this  reason,  specification  matching  must  be  used  as  a  tighter 
filter  to  identify  reuse  components. 

Specification  matching  at  a  simple  level  is  merely  a  logical  equivalence  or  logical 
implication  between  the  query  specification  and  the  component  specification  [ROLL90]. 
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At  a  deeper  level,  matching  can  be  divided  into  Pre/Post  Matches  and  Predicate  Matches. 
Pre/Post  Matches  are  comparisons  of  the  query  pre-conditions  against  the  component 
pre-conditions  and  the  query  post-conditions  against  the  component  post-conditions. 
There  are  a  variety  of  matches  depending  on  the  nature— implication  or  equivalence— and 
the  direction  of  comparison.  The  Predicate  Match  addresses  all  predicates  in  the 
specification  of  the  query  and  component.  Again  there  is  a  variety  mirroring  those  of  the 
Pre/Post  Matches  [ZARE95b]. 

2.5  Quality  Air  Force  Criteria 

2.5.1  QAF  History.  As  defense  budgets  decrease  and  it  is  required  to  do  more  with 
less,  the  Department  of  Defense  (DOD)  has  chosen  to  use  Total  Quality  Management 
(TQM)  as  the  means  for  increasing  productivity,  quality,  and  customer  satisfaction.  One 
well-known  method  for  implementing  TQM  is  the  Malcolm  Baldrige  National  Quality 
Award  (MBNQA).  The  MBNQA,  established  in  1987  and  named  after  then-Secretary  of 
Commerce  Malcolm  Baldrige,  has  a  strong  reputation  as  a  quality  award.  It  is  awarded 
annually  to  companies  that  exemplify  the  quality  ideals  and  concepts  embodied  in  the 
criteria  [KAN95].  Because  of  this  strong  reputation,  the  Air  Force  arm  of  the  DOD  has 
chosen  the  MBNQA  as  the  basis  for  implementing  TQM  in  Air  Force  organizations.  The 
Air  Force  program  is  known  as  Quality  Air  Force  (QAF),  and  the  criteria  are  referred  to 
as  the  QAF  criteria  [DEPA95b]. 

2.5.2  Overview  of  the  QAF  Criteria.  The  criteria  are  built  upon  four  basic  elements 
as  seen  in  Figure  1  [DEPA95c].  The  driver  is  organizational  leadership.  Organizational 
leadership  drives  the  planning  process  in  a  comprehensive  approach  to  setting  goals  and 
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making  plans  based  on  customer  requirements.  Progress  toward  goals  is  determined  by 
measures  of  progress  also  used  to  manage  the  system.  Ultimately,  the  goal  is  to  increase 
value  to  the  customer  [DEPA95a,  DEPA95c,  FALL93]. 


To  be  successful,  my 
organization  must  achieve... 

7.0  Customer 

Focus 

6.0  Performance 

Results 

GOAL 

We  will  produce  results 

7.0  Customer 

Focus 

5.0  Process 
Management 

through  goals,  objectives 
and  action  plans  for  key 
systems... 

(These  will  provide  focused 
activity  for  performance  and 
improvement) 


4.0  Human  Resource 
Development  &  Management 


MEASURES 

OF 

PROGRESS 


2.0  Information  &  Analysis 


Our  goals  and  plans  will  be  the 
result  of  a  comprehensive  and 
deliberate  planning  process... 


PLANNING 

PROCESS 


Establishing  direction  and 
providing  support  requires.. 


1.0  Leadership 


DRIVER 


Figure  1  Quality  Air  Force  Criteria.  [DEPA95c] 

These  four  elements  provide  the  basis  for  assessing  a  “unit’s  leadership  and 


management,  as  shown  in  mission  and  functional  area  performance,  installation  support, 
people  programs,  service  to  customers,  and  conformance”  to  customer  requirements 


[DEPA95a]. 

2.5.3  QAF  Criteria  Structure.  The  QAF  criteria  are  functionally  structured  into 
seven  inter-related  Categories  to  aid  assessment.  The  categories  are  sub-divided  into  24 
Examination  Items,  which  are  further  divided  into  54  Areas  to  Address.  Each 
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examination  item  is  scored  on  three  dimensions:  approach,  deployment,  and  results.  The 


approach  is  how  the  organization  addresses  the  requirement.  The  deployment  is  the 
extent  to  which  all  areas  of  the  requirement  are  addressed,  and  results  “refer  to  the 
outcomes  in  achieving  the  purposes  given  in  the  item”  [DEPA95c].  All  Air  Force  units 
are  required  to  conduct  QAF  assessments  (QAFA)  [DEPA95a].  The  next  section 
provides  short  descriptions  of  each  of  the  seven  categories. 

2.5.4  QAF  Categories. 

2. 5.4.1  Leadership.  This  category  provides  the  focus  within  the  criteria  for  the 
organizational  leadership  and  strategic  direction.  Leadership  is  the  driver  for  moving  the 
organization.  The  category  addresses  the  entire  management  infrastructure  and  how  it 
translates  mission  objectives  into  performance  results  [DEPA95c]. 

2. 5.4.2  Information  and  Analysis.  This  category  covers  the  management  of  the 
key  information  required  to  assess  and  improve  the  organization’s  overall  performance. 
The  processes  in  this  category  provide  the  mechanism  for  senior  leadership  to  align 
organizational  processes  with  strategic  directions.  Furthermore,  this  category  provides 
the  foundation  for  all  measures  of  progress  [DEPA95c]. 

2. 5.4.3  Strategic  Planning.  Strategic  planning  involves  setting  a  vision  for  the 
organization  based  on  customer  needs  and  operational  performance  requirements,  and 
translating  that  vision  into  a  coherent  plan  for  achieving  quality,  increasing  customer 
satisfaction,  and  improving  business  performance.  Key  issues  in  this  category  are 
effective  deployment  of  plans,  continuous  improvement  of  processes,  and  optimization  of 
resources  [DEPA95c]. 
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2. 5.4.4  Human  Resource  Development  and  Management.  This  category  is  the 
focal  point  in  the  criteria  for  all  human  resource  issues  such  as  training,  morale,  and 
quality  of  life.  The  purpose  of  the  category  is  to  ensure  human  resources  are  effectively 
managed  to  create  a  high  performance  workplace  that  supports  the  strategic  direction  of 
the  organization  [DEPA95c]. 

2.5.4.5  Process  Management.  Process  management  emphasizes  the 
importance  of  managing  the  processes  essential  to  providing  products  and  services  to 
meet  customer  needs.  This  includes  production  line  processes,  as  well  as  support 
processes.  Proper  process  management  is  a  principal  part  of  the  capability  to  accomplish 
strategic  goals  [DEPA95c]. 

2.5.4.6  Performance  Results.  In  short,  this  category  is  a  measure  of  how  well 
an  organization  meets  its  goals.  Data  is  collected  based  on  product  and  service  quality, 
operational  performance,  customer  satisfaction,  and  mission  effectiveness  indicators  to 
provide  “real-time  information  for  evaluation  and  improvement  of  processes.” 
[DEPA95C]. 

2. 5. 4. 7  Customer  Focus  and  Satisfaction.  This  category  captures  the  essence 
of  the  QAF  criteria.  It  is  both  a  goal  and  a  measure  of  progress.  As  a  goal,  customer 
focus  is  the  foundation  for  determining  organizational  priorities  and  planning 
improvement  activities.  As  a  measure  of  progress,  customer  satisfaction  helps  the 
organization  determine  development  toward  the  customer  focus  goals  [DEPA95c]. 
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2.6  Capability  Maturity  Model  for  Software 


2.6.1  CMM  History.  At  about  the  same  time  the  DOD  was  adopting  TQM,  the  Air 
Force  was  searching  for  a  method  to  assess  the  software  capability  of  its  contractors.  The 
Air  Force  turned  to  the  Software  Engineering  Institute  (SEI)  for  help.  Watts  Humphrey  of 
the  SEI  applied  the  quality  principles  of  W.  Edwards  Deming,  Joseph  Juran,  and  Philip 
Crosby  to  the  software  field  and  developed  an  initial  framework  for  assessing  process 
capability.  Using  knowledge  gained  from  using  the  framework  and  associated 
questionnaire,  along  with  comprehensive  feedback  from  government  and  industry,  the 
SEI  extended  the  framework  into  an  extensive  model  of  organizational  practices  in  1991. 
The  model  was  updated  in  1993  based  on  additional  feedback  from  government  and 
industry.  The  current  version  of  the  CMM  is  contained  in  CMU/SEI-93-TR-24 
[PAUL93a].  The  key  praetices  are  listed  in  CMU/SEI-93-TR-25  [PAUL93b]. 

2.6.2  CMM  Structure.  The  CMM  is  functionally  structured  into  18  Key  Process 
Areas(KPAs).  KPAs  are  divided  into  five  subcategories  called  Common  Features.  The 
Activities  Performed  Common  Feature  describes  the  activities  an  organization  should 
perform  in  the  respective  KPA.  The  other  Common  Features  relate  to  institutionalizing 
the  activities  described  [PAUL93b].  The  following  section  previews  the  CMM. 

2.6.3  CMM  Overview.  The  primary  purpose  of  the  CMM  is  to  help  software 
organizations  gain  control  of  their  software  process,  changing  their  culture  to  one  of 
software  engineering  excellence,  and  ultimately  decreasing  risk  while  increasing 
productivity  and  quality.  To  fulfill  this  purpose,  the  CMM  is  structured  in  a  manner  that 
facilitates  an  evolutionary  approach  to  improving  processes  [PAUL93a].  It  is  divided 


24 


into  levels  which  characterize  the  process  maturity  of  an  organization  as  it  progresses 
toward  continuous  improvement.  Figure  2  captures  the  essence  of  the  CMM  by  depicting 
each  Maturity  Level  along  with  the  focus  and  key  process  areas  which  describe  that  level 
[PAUL93a]. 


Capability  Maturity  Model  (CMM) 


Level 

Focus 

Kev  Process  Areas 

Result  ^ 

5 

Optimizing 

Continuous 

Process 

Improvement 

Defect  prevention 

Technology  innovation 

Process  cnange  management 

1 

4 

Managed 

Product  and 
Process  Quality 

Quantitative  Process  Mgt 
Software  Quality  Management 

3 

Defined 

Engineering 

Process 

Organization  process  focus 
Organization  process  defn. 
Peer  reviews 

Training  program 

Intergroup  coordination 
Software  product  engineering 
Integrated  software  mgt. 
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Repeatabie 

Project 

Management 

Software  project  planning 
Software  project  tracking 
Software  subcontract  mgt. 
Software  quality  assurance 
Software  configuration  mgt. 
Requirements  mgt. 

1 

initiai 

Heroes 

Figure  2  Capability  Maturity  Model  (CMM)  for  Software.  [PAUL93a]. 

Each  maturity  level  represents  a  plateau  in  an  organization’s  progression  toward 


continuous  improvement.  The  Focus  column  lists  the  issues  which  characterize  an 
organization  at  that  maturity  level.  The  Key  Process  Areas  are  the  critical  competencies 
the  organization  must  have  mastered  to  have  reached  that  maturity  level.  The  Result 
column  depicts  the  payoff  for  an  organization  moving  up  the  maturity  model-as  risk 


decreases,  productivity  and  quality  increase. 
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III.  Approach 


3.1  Introduction 

As  stated  in  Section  1.3,  the  overall  goal  of  this  research  is  to  demonstrate  the  use  of 
signature  matching  and  specification  matching  to  integrate  the  process  requirements 
imposed  by  the  CMM  and  the  QAF  criteria.  To  accomplish  this  goal,  the  CMM  and  QAF 
criteria  are  viewed  as  sets  of  process  requirements  for  organizations  to  fulfill.  Based  on 
Osterweil’s  conception  of  software  process  as  software  [OSTE87],  the  process 
requirements  are  analyzed  as  software  requirements  using  software  analysis  methods 
such  as  functional  decomposition,  object  diagrams,  and  formal  specification.  Each  set  of 
requirements  is  analyzed,  decomposed,  and  logged  using  a  simple  framework.  The 
signatures  are  specified  and  matched  using  contextual  information  as  a  backdrop. 
Requirements  requiring  further  examination  are  formally  specified  using  the  specification 
language  Z,  and  the  specifications  compared.  The  final  integrated  set  of  requirements 
represents  all  process  requirements  enjoined  by  the  two  models;  thus,  it  is  applied  against 
a  real  process  description  to  identify  unmet  requirements  in  the  process  description,  or 
omissions  in  the  integrated  set  of  requirements.  The  following  paragraphs  expound  on 
this  approach. 

3.2  Requirements  View  of  Models 

The  QAF  criteria  and  the  CMM  are  often  used  as  references  to  set  organizational 
goals  and  plan  process  improvements.  Viewed  from  a  slightly  different  perspective,  these 
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two  models  provide  a  description  of  what  an  organization  must  do  to  achieve 
organizational  goals  and  realize  process  improvements.  This  description  is  a 
requirements  specification  for  the  organizational  system.  The  overviews  of  both  models 
corroborate  the  requirements  specification  view.  The  QAF  criteria  are  depicted  as  a  non- 
prescriptive,  yet  comprehensive  set  of  process  requirements  for  organizations  to  fulfill 
[DEPA95c].  The  CMM  verbiage  is  less  direct,  using  the  word  criteria  instead  of 
requirements.  The  CMM  is  described  as  a  set  of  “criteria  describing  the  characteristics  of 
mature  software  organizations”  [PAUL93a].  Hence,  both  models  are  considered  as 
informal  requirements  documents. 

The  next  issue  concerns  what  to  do  with  these  requirements  documents.  The  goal  of 
this  research  is  to  integrate  the  two  sets  of  requirements  into  one  comprehensive, 
consistent  set.  However,  in  their  current  form.  Air  Force  software  organizations  have 
difficulty  integrating  the  models.  One  major  difficulty  relates  to  the  scope  of  the  models. 
The  CMM  is  more  project  focused  with  a  flavor  of  the  organization  level.  By  contrast, 
the  QAF  criteria  is  more  organization  focused  with  a  flavor  of  the  project  level.  The 
different  scopes  make  them  complementary  in  concept,  but  in  practice  the  exact 
boundaries  and  interactions  between  the  models  are  difficult  to  discern.  Another 
difficulty  relates  to  the  language  used  by  each  model.  The  QAF  criteria  is  meant  for  a 
broad  range  of  organizational  missions.  The  language  is  very  general;  it  does  not  mention 
specific  roles,  documents,  or  organizational  structures.  Conversely,  the  CMM  is  meant 
for  software  organizations.  It  discusses  roles  such  as  the  project  software  manager, 
documents  such  as  the  software  development  plan,  and  organizational  structures  such  as 
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the  software  engineering  group.  Due  to  such  differences,  it  is  necessary  to  translate  the 
models  into  a  form  more  amenable  to  integration.  The  first  step  toward  that  objective 
involves  analyzing  and  decomposing  each  model  into  the  lowest  level  requirements. 

S.3  Functionally  Decompose  Requirements 

The  QAF  criteria  and  the  CMM  are  each  structured  along  functional  lines,  as 
described  in  Section  2.5.3  and  Section  2.6.2,  respectively.  The  functional  structures  serve 
as  backdrops  for  decomposing  the  models  even  further.  The  aim  is  to  decompose  the 
models  until  all  requirements  represent  a  process  or  activity  with  a  single  output  or  two  to 
three  tightly-coupled  outputs.  Decomposing  to  this  level  more  readily  allows 
comparisons  between  requirements.  Another  motivation  for  decomposing  to  this  level 
relates  to  complexity.  At  this  lowest  level,  the  complexity  resulting  from  the 
relationships  and  interfaces  between  multiple  functional  components  is  greatly  mitigated. 
Each  low-level  requirement  is  more  easily  understood  and  managed. 

Understanding  the  requirements  is  the  key  to  building  any  complex  system.  The 
requirements  analyst  must  have  a  solid  grasp  of  the  problem  domain  in  order  to  constrain 
it  sufficiently  to  derive  the  solution  space.  The  analyst  obtains  the  knowledge  from  the 
user’s  problem  statement  or  requirements  document.  The  analysis  process  produces  a 
more  concise  description,  while  eliminating  redundancy,  inconsistency,  and  ambiguity 
[RUMB91].  Although  the  goal  of  this  research  is  not  to  build  a  system,  understanding 
the  requirements  is  no  less  important.  The  CMM  and  QAF  criteria  are  considered  user 
requirements  documents.  Each  document  must  be  well-understood,  and  transformed  into 
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a  concise,  consistent,  unambiguous  format.  The  result  of  this  step  is  a  restatement  of 
requirements  from  both  models  in  a  simple,  understandable  format. 

Managing  the  numerous  requirements  is  another  important  aspect  of  this  approach. 
This  approach  uses  a  framework  as  the  means  to  manage  the  requirements.  The 
framework  includes  the  following  fields:  Name,  ID,  Purpose,  Agents,  Correlates  to. 
Inputs,  Outputs,  Entrance  Criteria,  Exit  Criteria,  and  Comments.  In  addition  to  being  a 
management  tool,  the  framework  serves  as  an  informal  method  of  communicating  the 
results  of  requirements  analysis  to  the  sponsor  of  the  research.  The  idea  of  using  this  type 
of  framework  is  taken  from  Hollenbach  and  Frakes  [HOLL96].  Their  framework  is  used 
to  document  and  define  processes,  and  place  them  in  a  process  library  for  the  purpose  of 
reuse.  Since  this  approach  deals  completely  with  process  requirements,  as  opposed  to 
actual  processes,  the  framework  used  here  is  far  less  elaborate. 

3.4  Integrate  Requirements  into  One  Set 

Integrating  the  two  sets  of  requirements  from  the  respective  models  into  a  single 
non-redundant,  complete  set  of  requirements  is  the  crux  of  this  problem.  The  primary 
vehicle  for  eliminating  redundancy  in  this  approach  is  signature  matching.  Signature 
matching  involves  comparing  the  signatures,  or  interfaces,  to  identify  potentially  similar 
components.  The  signature  of  a  requirement  is  specified  by  the  types  associated  with  the 
inputs  and  outputs  of  the  process  the  requirement  represents.  The  signature  is  the 
interface  of  the  process.  As  the  requirements  are  decomposed  to  the  lowest  level,  the 
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types  of  the  inputs  and  outputs  are  identified  and  recorded  for  use  in  signature  matching, 
which  is  explained  in  the  following  section. 

3.4.1  Signature  Matching.  Signature  matching  is  paramount  to  this  research. 
Recall  that  signature  matching  entails  comparing  the  interfaces,  or  input/output  types  of 
functions  or  modules.  (No  concern  is  paid  here  to  the  order  of  types  in  the  signature.  The 
actual  process  of  matching  signatures  is  primarily  accomplished  using  a  spreadsheet,  thus 
the  order  is  easily  transformed.  Zaremski  and  Wing  illustrate  an  automated  proof  system 
which  must  handle  the  transformation  without  human  intervention  [ZARE95a].)  The 
general  form  of  the  signature  match  is: 

Signature  Match(q,M,C)  =  {c  e  C:  M(c,q)} 

In  this  research,  the  process  requirements  from  both  models  are  considered  to  be 
functions  that  make  up  the  component  library  C.  A  process  requirement  is  drawn  from  C 
to  act  as  the  query  q.  (In  theory,  this  specification  may  be  drawn  at  random;  however,  in 
practice,  the  requirements  are  sorted  by  signatures  and  requirements  likely  to  be 
redundant  are  chosen.)  The  match  predicate  M  for  this  approach  is  Exact  Match  or 
Partial  Match.  The  Z  form  of  Exact  Signature  Match  and  Partial  Signature  Match  for 
this  approach  follow  in  Figures  3  and  4: 

_esm_  :  Procreq  Procreq 

PiesmP2<^ 

ran  P,. inputs  =  ran  P2.inputs  a 
ran  P /.outputs  =  ran  P2.outputs 

Figure  3  Exact  Signature  Match. 
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_psm_  :  Procreq  <->  Procreq 
P/psm  P2  <=> 

ran  P /.inputs  c  ran  P2.inputs  a 
ran  P /.outputs  c  ran  P2.outputs 

Figure  4  Partial  Signature  Match. 

As  an  example,  the  signature  of  a  process  to  measure  a  product  might  look  like: 

MeasureProduct:  {product},  {indicator}  - >  {data} 

Another  process  to  measure  the  quality  of  a  product  might  be  represented  by  the 
following  signature: 

MeasureQuality:  {product}  - >  {data} 

In  this  situation,  it  is  desired  to  identify  these  as  potentially  matching  processes. 
Exact  Signature  Match  would  fail,  but  Partial  Signature  Match  would  identify  these  as 
potentially  redundant  requirements.  In  this  simple  case  a  decision  can  be  made  at  this 
point  to  eliminate  the  less  general  of  the  two.  In  this  example,  MeasureQuality  would  be 
eliminated  in  favor  of  MeasureProduct,  and  any  information  in  the  Correlates  to  and 
Comments  fields  of  MeasureQuality  would  be  included  in  MeasureProduct.  For  this 
research,  signature  matches  along  with  contextual  information  generally  suffice  to 
determine  redundancies.  However,  in  more  complicated  situations,  specification 
matching  is  needed  to  determine  if  two  specifications  match  under  tighter  constraints. 

3.4.2  Specification  Matching.  Specification  matching  is  used  sparingly  in  this 
approach  since  most  matches  may  be  determined  using  signature  matching  outcomes  and 
contextual  information.  Nonetheless,  some  situations  warrant  this  level  of  comparison. 
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The  objective  of  the  step  is  to  represent  the  process  requirements  in  first  order  predicate 
logic.  This  can  be  done  in  Z. 

3.4.2. 1  Formally  Specify  the  Appropriate  Requirements  in  Z.  The  information  in 
the  informal  framework  is  translated  into  the  formal  specification  language  Z.  A  formal 
language  such  as  Z  offers  a  more  precise  description  of  requirements  without  sacrificing 
brevity.  In  addition  to  precision,  a  formal  language  allows  the  use  of  mathematics  as  a 
means  of  eliminating  ambiguity  and  demonstrating  parts  of  the  specification  [POTT91]  . 

Formal  languages  also  facilitate  abstraction  during  requirements  analysis  and 
specification.  Abstraction  plays  a  significant  role  in  this  approach.  Both  models  refer  to 
a  number  of  entities  such  as  people,  data,  products,  processes,  etc.  Generally,  the  internal 
structure  of  an  entity  is  unimportant  to  analyzing  the  process  requirement  in  this 
approach.  The  set  theory  of  Z  allows  the  establishment  of  global  sets  representing  these 
abstractions.  For  example,  a  global  set  WORKFORCE  may  be  used  to  represent  all  the 
members  of  an  organization.  In  this  form,  specifications  are  compared  to  determine  if 
matches  exist. 

3.4.2.2  Match  Specifications.  The  formally  specified  requirements  are  compared 
using  specification  matching  as  described  by  [ZARE95b].  The  match  predicates  for 
specification  matching  are  those  associated  with  Pre/Post  Matches.  The  internal 
behaviors  of  the  processes  are  not  of  consequence,  but  rather  the  pre-  and  post-conditions. 
The  Z  forms  of  the  Exact  Specification  Match  and  Partial  Specification  Match  are  given 
in  Figures  5  and  6: 
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_espm_  :  Procreq  Procreq 

P 1  espm  P2  <=> 

P 1  esm  P2 

Pi.pre  <=>P2.pre 

Pi.post  0  P2.post 

Pi.subproc  =  P2.subproc 

Figure  5  Exact  Specification  Match 

_pspm_  :  Procreq  <->  Procreq 

PipspmP2^ 

Pipsm  P2 

Pi.pre  =>  P2pre 

P2.post  =>  Pi.post 

Pi.subproc  QP2.subproc 

Figure  6  Partial  Specification  Match 


In  the  Partial  Specification  Match,  Pi.pre  =>  P2-pre,  but  the  order  is  reversed  for  the  post¬ 
conditions,  namely  P2.post  Pi.post.  Consequently,  if  the  relationship  between  pre¬ 
conditions  and  post-conditions  is  also  pre  post,  then  it  is  guaranteed  that  P/  ^  P2. 
This  indicates  P2  is  the  more  general  of  the  two  process  requirements.  Of  course,  in  the 
Exact  Signature  Match  the  match  predicate  is  equivalence  and  the  order  does  not  matter. 

3.5  Verify  Integrated  Set 

To  verify  the  integrated  set  completely  represents  both  models,  each  Area  to  Address 
from  the  QAF  criteria  and  Key  Practice  from  the  CMM  is  correlated  to  the  requirements 
that  specify  it.  This  ensures  the  models  are  adequately  covered.  Another  means  ol 
verification  is  to  compose  requirements  (i.e.,  the  processes  they  represent)  into  process 
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descriptions  which  represent  a  functional  area  such  as  process  management.  Composing 
requirements  in  this  manner  also  provides  insight  into  the  compatibility  between  the 
models. 

3.6  Apply  to  Process  Description 

The  result  of  the  integration  step  achieves  the  overall  goal  of  this  research-to 
demonstrate  the  use  of  signature  and  specification  matching  to  integrate  the  process 
requirements  imposed  by  the  CMM  and  QAF  criteria.  However,  an  additional  objective 
is  to  demonstrate  the  use  of  this  set. 

In  the  software  lifecycle,  the  requirements  phase  culminates  in  a  requirements 
document  describing  what  the  system  does.  The  design  phase  initiates  to  determine  how 
the  system  behaves  to  meet  those  requirements.  In  this  research,  the  integrated  set  of 
process  requirements,  along  with  the  associated  framework  documentation  comprise  the 
requirements  document.  Naturally  this  document  is  used  to  design  processes  to  meet  all 
the  stated  requirements. 

The  sponsor  of  this  research  (as  well  as  many  other  Air  Forces  software 
organizations)  already  has  a  process  design  intended  to  meet  these  requirements.  Thus, 
the  requirements  document  is  used  as  a  validation  tool  to  determine  if  the  design  of 
Standard  Systems  Group’s  systems  engineering  process  (SEP)  meets  the  design 
requirements.  The  validation  is  accomplished  simply  by  tracing  requirements  identified 
by  the  requirements  document  to  actual  processes  in  the  SEP.  The  absence  of  processes 
to  fulfill  requirements  indicates  inadequacies  in  the  SEP  design.  Since  the  QAF  criteria 
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and  especially  the  CMM  identify  only  key  process  requirements  (see  Section  1.5.3),  some 
SEP  processes  may  not  trace  back  to  the  requirements  document.  The  necessity  of  these 
processes  must  be  determined  by  other  requirements  (which  could  also  be  integrated  into 
the  requirements  document  using  this  approach).  Backwards  tracing  also  acts  as  a  partial 
verification  of  the  requirements  document  by  possibly  illuminating  missing  requirements. 

The  requirements  trace  will  be  done  on  a  limited  basis  to  demonstrate  the  utility  of 
the  requirements  document.  If  the  processes  in  the  SEP  were  formally  specified  (and 
given  the  appropriate  tools),  formal  queries  could  be  formed  to  trace  process  requirements 
to  all  occurrences  in  the  design— in  this  case,  the  SEP. 
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IV.  Analysis  and  Results 


This  chapter  discusses  analysis  of  the  research  approach,  along  with  intermediate 
and  final  results.  The  first  section  examines  the  approach  itself  and  its  effectiveness.  The 
next  section  covers  issues  related  to  the  analysis  and  decomposition  of  the  two  models. 
Finally,  the  last  section  provides  a  look  at  the  results  of  the  approach  at  the  intermediate 
steps,  as  well  as  at  the  end. 

4.1  Analysis  of  Approach 

4.1.1  Functional  Decomposition.  Functional  decomposition  is  a  valuable  step  in 
this  approach.  The  purpose  of  decomposing  the  requirements  is  to  reduce  complexity  of 
multiple  inputs,  outputs,  and  conditions  on  a  process,  and  to  gain  deeper  understanding  of 
the  given  requirements.  The  deeper  understanding  provides  contextual  information 
necessary  for  making  decisions  on  which  requirement  specification  to  keep  when 
matching  signatures  and  specifications. 

Flowever,  the  purpose  of  this  step  may  be  accomplished  through  other  tools  or 
methods.  In  particular,  the  ad  hoc  use  of  tools  such  as  data  flow,  IDEFO,  and  entity- 
relationship  diagrams  may  be  helpful;  however,  to  receive  the  maximum  benefit  from 
these  tools,  they  must  be  planned  for,  and  integrated  into,  the  approach.  In  addition  to 
better  utilizing  tools,  different  methods  of  analysis  may  also  be  beneficial.  Although  the 
CMM  and  QAF  criteria  are  functionally  designed,  an  object-oriented  approach  to 
analyzing  these  models  may  be  better.  The  heart  of  this  approach  is  matching  the  process 
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requirement  signatures,  which  consist  of  the  input/output  types.  These  types  normally 
translate  into  object  or  object  classes  in  object-oriented  analysis.  Using  object-oriented 
analysis,  the  focus  is  on  input/output  types,  or  objects,  from  the  beginning  of  the 
approach,  thus  facilitating  signature  matching.  Additionally,  the  processes  (or  process 
requirements)  themselves  may  be  viewed  as  objects.  The  object  view  eases  the  task  of 
composing  integrated  processes  back  together  into  a  coherent  model  of  an  entire 
organization  or  some  piece  of  it,  such  as  a  division  or  project. 

4.1.2  Framework.  The  framework  has  a  twofold  purpose.  The  primary  purpose  of 
the  framework  is  as  a  communication  device.  In  this  role,  the  framework  is  very 
effective.  It  provides  a  standard  template  for  presenting  all  the  information  on  each 
requirement  to  the  customer.  The  framework  used  in  this  approach  is  a  greatly  scaled- 
down  version  of  Hollenbach  and  Frake’s  [HOLL96]  since  most  requirements  are  simply 
for  a  process  to  exist.  Hollenbach  and  Frake’s  framework  is  used  to  record  more  detailed 
information  on  processes,  such  as  tools,  procedures,  and  metrics.  Nonetheless,  with  a 
large  number  of  required  processes,  the  framework  can  quickly  get  unwieldy. 

The  secondary  purpose  of  the  framework  is  as  a  tool  for  managing  the  requirements 
as  they  are  gleaned  from  the  models.  As  a  requirements  management  tool  for  this 
approach,  the  framework  adds  little  value.  A  spreadsheet  is  a  much  better  alternative  for 
managing  the  requirement  during  the  decomposition  and  matching  steps.  With  the 
spreadsheet,  subsets  of  the  information  put  into  the  framework  are  easily  created,  thus 
enhancing  signature  matching.  However,  as  a  tool  for  managing  the  requirements  or 


38 


associated  processes  on  a  long-term  basis,  the  framework  is  a  good  choice.  Thus,  for  this 
approach,  the  framework  is  best  produced  near  the  end,  after  all  the  analysis  is  done. 

4.1.3  Use  of  Formal  Language.  The  use  of  a  formal  language  in  this  approach  is 
central  to  the  signature  and  specification  matching  paradigms.  However,  in  this  particular 
application  of  integrating  the  CMM  and  QAF  criteria,  using  a  formal  language  does  not 
add  a  great  deal  of  value.  The  primary  reason  for  this  is  the  nature  of  the  CMM  and  QAF 
criteria.  Both  models  are  descriptive,  rather  than  prescriptive.  They  tell  what  to  do,  but 
do  not  specify  how.  As  a  result,  the  requirements  derived  from  the  models  generally  state 
a  process  must  exist  and  be  used  by  an  organization,  but  seldom  specify  any  behavioral 
aspects  of  the  process.  Some  process  behaviors  are  specified  in  the  models,  but  these 
behaviors  may  be  viewed  as  sub-processes  instead  of  pre-conditions  or  post-conditions. 

There  is  also  a  secondary  reason  that  this  particular  application  of  the  approach  does 
not  benefit  significantly  from  a  formal  language.  The  secondary  reason  is  lack  of 
automation  for  the  formal  language.  For  this  application,  signature  matching  bears  the 
bulk  of  the  workload.  Although  Z’s  types  and  schemas  are  ideal  for  use  in  signature 
matching,  it  lacks  an  automated  proof-checker  and  associated  search  engine. 
Consequently,  Z  brings  little  to  the  signature  matching  table.  Most  of  the  signature 
matching  work  is  done  more  efficiently  by  a  spreadsheet.  Even  specification  matching  is 
as  easily  done  without  the  use  of  Z  or  another  formal  language. 

4.1.4  Modeling  in  Z.  Modeling  the  requirements  in  Z  is  a  bit  troublesome,  although 
not  directly  due  to  the  nature  of  Z.  The  troublesome  question  is  whether  to  model  ihe 


39 


process  requirements  as  static  objects  or  as  operations.  The  difference  may  be  seen  by 
considering  the  Z  schemas  in  Figures  7  and  8. 


—Procreq - 

name:  NAME 
id:  ID 

correlates:  P  STANDARDS 
agents:  p  Worker  set 
inputs:  P  ARTIFACT  x  TYPE 
outputs:  P  ARTIFACT  X  TYPE 
pre:  P PREDICATE 
post:  P  PREDICATE 
subproc:  p  Procreq 


inputs  ^  0 
outputs  ^  0 
agents  ^  0 
pre  =>  post 


Figure  7  Process  Requirement  as  a  Static  Object. 


In  Figure  7,  the  schema  describes  attributes  of  the  object  called  Procreq.  Procreq  is 
merely  a  translation  of  a  process  requirement  specified  in  the  CMM  or  QAF  criteria.  The 
information  related  to  the  required  process  is  provided  in  the  signature  using  the 
components:  name,  id,  correlates,  agents,  inputs,  outputs,  pre,  subproc,  and  post.  The 
predicate  part  of  the  schema  states  invariant  constraints  on  all  objects  of  this  type. 

The  schema  in  Figure  8  specifies  an  actual  process  (in  contrast  to  a  process 
requirement)  as  an  operation  on  the  organization.  Inputs  and  outputs  are  separate 
components,  and  pre-conditions  and  post-conditions  are  given  in  the  predicate  part  of  the 
schema.  Sub-processes  may  also  be  listed  in  the  predicate.  When  placed  in  the  predicate 
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in  this  way,  the  sub-processes  are  mandatory  parts  of  the  current  process.  The  schema, 
when  instantiated  with  actual  values,  is  the  skeleton  of  an  actual  process  specification.  It 
can  be  used  in  the  skeletal  form  as  a  query  for  more  complete  processes,  or  be  expanded 
to  serve  as  a  process  specification. 


—Process - 

AOrganization 
name:  NAME 
id:  ID 

correlates:  p  STANDARDS 
agents:  pWorkerset 
input  1:  TYPE 
input2:  TYPE 

subprocl:  Process 
subproc2:  Process 

output  1:  TYPE 
output 2:  TYPE 


prel 

pre2 

subproc I 
subproc2 

post! 

post2 


Figure  8  Process  Requirement  as  Operation. 


The  question  of  whether  to  model  the  process  requirements  as  objects  or  as 
operations  is  best  answered  based  on  the  application  of  the  approach.  In  this  particular 
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application,  process  requirements  are  modeled  as  objects  to  be  compatible  with 
[HIBD95].  This  issue  is  discussed  in  Section  6.3. 1.1. 

4.1.5  Signature  and  Specification  Matching.  Signature  matching  is  the  real 
workhorse  of  this  approach.  As  mentioned  in  Section  3.2,  merging  the  two  models  in 
their  present  form  is  quite  difficult.  The  difficulty  arises  in  large  part  from  the  semantics 
associated  with  the  process  requirements.  Terms  such  as  key  performance  drivers  and 
work  organizations  from  the  QAF  criteria,  and  requirements  allocated  to  software  and 
project’s  defined  software  process  from  the  CMM  are  difficult  to  translate  from  one 
context  to  another  because  they  hide  their  basic  identity  or  type.  However,  signature 
matching  focuses  on  the  syntax  of  requirements.  It  uses  the  fundamental  types  of  process 
artifacts,  not  the  names  of  artifacts.  In  other  words,  the  concept  of  signature  matching 
provides  a  method  for  distilling  out  semantics  and  leaving  syntax.  Once  matches  are 
found,  semantics  are  restored  to  provide  context  for  determining  a  true  match. 

Although  specification  matching  is  integrated  into  this  approach,  for  this  application 
it  is  used  sparingly.  Comparisons  based  on  matching  signatures  and  context  are  sufficient 
to  identify  most  redundant  requirements.  Specification  matching  is  not  needed  as  much 
due  to  the  nature  of  the  two  models,  as  described  above.  The  models  mostly  require  the 
existence  of  the  processes,  but  not  much  beyond  that.  Furthermore,  process  requirements 
are  compared  to  other  process  requirements,  not  full-blown  requirements  specifications, 
which  typically  have  more  information  to  consider. 
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4.2  Analysis  Issues 


4.2.1  Comments  on  the  Models. 

4. 2. 1.1  QAF  Criteria.  The  QAF  criteria  is  certainly  a  comprehensive 
document,  which  embodies  the  tenets  of  the  quality  movement.  However,  it  is  not 
particularly  well-written,  nor  well-structured  at  a  low  level.  The  structure  of  Categories, 
Items,  and  Areas  to  Address  do  not  adequately  partition  the  requirements.  A  single  Area 
to  Address  may  impose  several  process  requirements.  A  case  in  point  is  the  description 
of  the  very  first  Area  to  Address'. 

Area  l.l.a.  calls  for  information  on  the  major  aspects  of  senior  leadership  - 
creating  values  and  expectations,  setting  directions,  developing  and 
maintaining  an  effective  leadership  system,  and  building  organization 
capabilities.  Senior  leaders  need  to  reflect  these  values,  and  the  leadership 
system  needs  to  include  teamwork  at  the  headquarters  level.  [DEPA95c] 

There  are  several  process  requirements  embedded  in  these  two  sentences,  including  Set 

Values,  Set  Expectations,  Set  Directions,  Develop  Leadership  System,  and  Maintain 

Leadership  System.  In  addition  to  the  descriptions,  such  as  the  one  given  above,  the  QAF 

criteria  also  include  criteria  and  guidance  for  assessment.  Instead  of  the  descriptions  and 

assessment  criteria  reflecting  and  complementing  each  other,  the  two  often  identify 

different  requirements  related  to  the  same  Area  to  Address.  These  often  add  further 

requirements  for  the  organization  to  meet. 

Another  criticism  is  the  lack  of  pictures  or  diagrams.  The  diagram  shown  in  Section 
2.5.2  is  the  only  diagram  (other  than  linkage  diagrams)  for  understanding  the  criteria. 
This  diagram  is  insufficient  to  explain  the  cyclic  nature  of  the  QAF  system.  Process  flow 
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diagrams  showing  the  interaction  among  the  categories,  such  as  the  one  provided  by 
Brown  in  [BROW94],  page  224,  greatly  increase  understandability  of  the  QAF  system. 
The  readability  of  linkage  diagrams  mentioned  above  could  also  be  improved. 

4. 2. 1.2  CMM.  The  CMM,  by  contrast,  is  a  very  readable  document.  The 
structure  consisting  of  Key  Process  Areas  (KPA),  Goals,  Common  Features,  and  Key 
Practices  is  explained  up  front  and  used  throughout  the  document.  The  authors  use  a 
standard  template  to  relay  the  information  to  the  reader.  When  referencing  other  parts  of 
the  model,  the  CMM  identifies  the  exact  location  for  the  reference.  Although  no 
diagrams  appear  in  the  practices,  the  pictures  in  the  overview  sufficiently  convey  the 
essence  of  the  CMM.  Moreover,  the  CMM  explains  peculiar  terms  and  concepts  very 
well  in  the  overview  and  glossary  sections. 

4.2.2  Analysis  Decisions. 

4.2.2. 1  Relation  of  Inputs  to  Outputs.  All  inputs  are  assumed  to  be  non-empty, 
unless  otherwise  stated,  and  contribute  to  the  outputs.  Empty  inputs  may  occur  when  a 
process  requirement  is  specified  at  Maturity  Levels  2  (ML2)  and  3  (ML3)  of  the  CMM. 
At  ML3,  the  process  is  required  to  take  as  input  the  Project’s  Defined  Software  Process 
(PDSP),  but  at  ML2  this  formalized  process  does  not  yet  exist.  The  input  for  the  PDSP 
may  be  empty.  See  the  requirement  for  Project  Planning  in  Appendix  A,  page  A-42  for 
an  example.  The  assumption  that  all  inputs  contribute  to  producing  outputs  is  particularly 
relevant  to  process  requirements  that  specify  that  X  is  the  basis  for  A.  An  example  of  this 
situation  is  found  in  the  QAF  criteria  Area  1.2.b  where  it  specifies  that  “...stated  values 
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and  expectations  are  actually  the  basis  for  organization  actions  and  key  decisions” 
[DEPA95C]. 

42.2.2  Meta-Processes.  The  CMM  and  the  QAF  criteria  contain  a  number  of 
what  may  be  considered  meta-process  requirements.  Meta-processes,  as  mentioned  in 
Section  2.3.1,  are  processes  that  concern  the  development,  assessment,  measurement, 
improvement,  or  maintenance  of  a  process.  In  the  CMM,  meta-processes  are  located  in 
Measurement  and  Analysis  and  Verifying  Implementation,  in  addition  to  certain  KPAs, 
such  as  Organization  Process  Definition  and  Process  Change  Management,  that  are 
designed  as  meta-processes.  A  large  part  of  the  QAF  Criteria  falls  into  the  meta-process 
realm.  Categories  2  and  5,  in  particular,  involve  meta-processes,  but  also  portions  of 
other  categories  that  mention  measuring  and  improving  the  respective  processes.  Meta¬ 
processes  are  specified  with  one  process  requirement  in  the  framework,  then  correlated  to 
all  the  specific  references  and  once  to  general  references  in  the  models.  For  instance,  the 
requirement  to  Measure  Process  can  be  applied  to  any  process.  It  is  specified  once,  then 
correlated  to  specific  references,  such  as  in  the  CMM  Quantitative  Process  Management 
Activity  4,  and  to  general  references,  such  as  CMM  Measurement  and  Analysis  for  every 
Key  Process  Area. 

4.2.2.3  CMM  -  Other  Common  Features.  Processes  specified  in  the  Other 
Common  Features  (OCF)  of  the  CMM  are  used  to  help  establish  and  institutionalize 
production  processes  in  the  organization.  In  describing  the  institutionalization  processes, 
there  are  a  few  key  phrases  that  merit  special  attention.  First  is  the  phrase  “the  project  (or 
organization)  follows  a  written  organizational  policy  ...”  from  the  Commitment  to 
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Perform  OCF  [PAUL93b].  It  is  explicitly  stated  in  the  CMM,  but  is  implicitly  embodied 
in  the  QAF  in  requirements  to  align  plans,  and  determine  key  performance  drivers  and 
objectives  based  on  goals.  This  is  not  so  much  a  requirement  for  a  process  as  it  is  a  pre¬ 
condition  for  other  required  processes.  However,  it  is  not  listed  as  a  pre-condition  to 
every  process  requirement.  Instead,  an  explicit  process  requirement  is  included  once  in 
the  framework  and  correlated  to  the  appropriate  references  in  the  models.  The  second 
special  phrase  occurs  in  the  Ability  to  Perform  OCF.  The  phrase  is  “adequate  resources 
and  funding  are  provided  for  ...”  [PAUL93b].  This  phrase  also  should  apply  to  every 
process  executed  in  the  organization  and  is  not  explicitly  listed  as  a  pre-condition  for  each 
process.  Again,  it  is  specified  as  a  separate  requirement.  The  phrases  “...  are  trained  ...” 
and  “...  receive  orientation  ...”  in  the  Ability  to  Perform  OCF  are  similar  situations  and  are 
treated  the  same  way  as  stated  before.  Finally,  the  phrase  “...  according  to  a  documented 
procedure”  occurs  in  the  Activities  Performed  Common  Feature.  This  phrase  is  applied  to 
many  activities  in  the  CMM  to  emphasize  repeatability  and  institutionalization 
[PAUL93b].  The  assumption  of  this  analysis  is  that  procedures  are  documented  as  part  of 
a  process,  hence  should  not  be  included  as  an  input  to  the  process. 

There  is  one  final  note  on  the  exclusion  of  certain  conditions  or  inputs.  Although 
there  are  some  equivalent  ideas  in  the  QAF  criteria,  these  phrases  are  unique  to  the  CMM, 
Thus  including  these  preconditions  and  inputs  contributes  little  to  the  overall  integration 
goal. 

4.2.2.4  Naming  Requirements.  The  names  of  the  process  requirements  are 
generally  drawn  directly  from  the  models,  though  in  some  cases,  names  are  changed  to 
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make  them  more  generic  and  inclusive.  These  changes  mostly  occur  with  the  CMM  since 
process  and  agent  names  are  domain  specific.  The  term  subcontractor  is  used  in  the 
CMM,  while  supplier  is  used  in  the  QAF  criteria.  This  research  opts  for  the  more  general 
term,  thus  Plan  Subcontractor  Work  becomes  Plan  Supplier  Work. 

Consistency  in  naming  process  requirements  is  also  an  aim.  For  example,  all  uses  of 
Evaluate  should  be  for  similar  situations  and  ideally  result  in  the  same  output. 
Specifically,  Evaluate  Process  and  Evaluate  Supplier  both  involve  evaluating  and  both 
have  actions  as  outputs.  Other  terms  like  Assess,  Supplier,  Measure,  and  Review  are  used 
consistently  throughout  the  framework. 

4.2.2.5  Agents  versus  Inputs.  For  the  most  part,  people,  or  groups  of  people, 
are  designated  as  agents  in  the  framework.  Agents  are  those  who  conduct  or  perform  the 
processes.  In  a  few  cases,  however,  people  or  groups  are  designated  as  inputs  to  the 
process  and  treated  as  artifacts.  In  still  other  cases,  the  same  people  are  treated  as  both 
agent  and  input.  If  the  people  or  group  are  involved  in  the  process,  but  take  no  active 
part,  they  are  considered  as  inputs  or  artifacts.  This  occurs  in  situations  such  as 
identifying  and  selecting  customer  groups.  In  these  cases,  an  attempt  to  distinguish 
between  the  two  is  made  by  naming  the  agent  Worker  and  the  input  Member,  for 
example.  Worker  implies  action,  whereas  Member  implies  belonging.  For  those 
processes  that  employ  the  same  people  as  agent  and  input,  the  same  name  is  used  for  the 
agent  and  input.  An  instance  of  this  situation  is  the  Evaluate  Member  process 
requirement.  The  members  being  evaluated  are  included  as  agents  and  as  inputs  to  this 
process.  The  rationale  is  that  the  process  is  being  performed  on  the  members,  and  the 
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members  play  an  active  role  in  their  evaluations,  as  in  Air  Force  mandated  feedback 
sessions. 

4.2.3  Artifact  Types. 

4.2.3. 1  Hierarchy  of  Data.  Both  models  require  organizations  to  collect  large 
amounts  of  relevant  process  and  product  data.  In  this  approach,  the  type  DATA  is  used 
for  any  data  referred  to  by  the  models.  However,  output  names  uniquely  identify  the 
source  or  the  characteristics  of  the  data. 

4.2. 3.2  Data  and  Analysis.  The  DATA  type  is  used  to  imply  raw  data,  whereas 
the  ANALYSIS  type  is  used  to  imply  analyzed  data.  Raw  data  are  the  primary  output  of 
measurement  and  assessment  processes,  and  the  secondary  output  of  various  other 
processes.  Raw  data  are  the  input  to  only  a  few  process  requirements  other  than  Analyze 
Data.  In  general,  data  are  assumed  to  be  analyzed  before  being  used  by  other  processes. 

4.2.3.3  Actions.  The  ACTION  type  is  the  output  of  reviews,  evaluations,  and 
audits,  along  with  various  other  process  requirements.  As  an  output  of  a  process 
requirement,  the  ACTION  type  is  considered  a  special  form  of  information  that  describes 
sets  of  possible  operations  to  be  performed.  The  type  does  not  imply  the  actions  are 
actually  executed  as  sub-processes  or  outputs  of  a  process.  For  this  application,  the  subtle 
difference  does  not  have  an  impact,  but  the  difference  would  have  an  impact  in  building 
an  executable  model  based  on  these  specifications.  Precisely,  the  decision  must  be  made 
to  view  the  output  actions  as  operations  to  perform-in  which  case  the  actions  may  be  put 
on  an  event  queue  and  eventually  executed-or  as  a  special  form  of  information,  as  in  this 
application. 
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4.2. 3.4  Products.  The  PRODUCT  type  is  used  for  work  products  and  end 
products.  It  is  a  super  type  that  encompasses  practically  any  of  the  other  artifact  types  in 
certain  situations.  A  case  in  point  concerns  the  REQUIREMENT  type.  Product 
requirements  specified  by  the  user  are  considered  of  type  REQUIREMENT,  but  may  also 
be  a  PRODUCT  type  when  in  the  form  of  a  software  requirements  document  (SRD). 
Review  Allocated  Requirements  is  used  to  review  the  allocated  requirements,  which  are 
the  REQUIREMENT  type,  to  ensure  requirements  are  feasible,  testable,  correct,  etc. 
Review  Product  is  used  to  review  the  SRD,  which  is  a  PRODUCT  type,  to  ensure  the 
product  meets  organizationally-established  criteria. 

4.2.3.5  Plans  and  Planning.  The  QAF  criteria  specifies  a  number  of  planning 
processes  and  the  CMM  requires  a  number  of  plans  at  the  organization  and  project  levels. 
The  importance  of  plan  requirements  lies  not  in  the  documents  themselves,  but  in  the 
process  of  planning.  The  process  of  planning  is  fundamentally  the  same  for  each  of  the 
planning  processes;  despite  this,  there  are  eleven  planning  requirements  in  the  framework. 
One  process  requirement  addresses  strategic  level,  or  organization  planning,  another 
addresses  tactical,  or  project  planning.  These  two  process  requirements  have  matching 
signature  and  specifications,  but  it  is  felt  the  two  demand  vastly  different  considerations 
and  require  different  skills,  and  are  thus  separated.  Other  planning  requirements  are  very 
specific  to  an  area,  but  may  employ  the  same  methods.  Examples  are  Plan  Community 
Involvement,  Plan  Peer  Review,  and  Develop  Integration  Test  Plan. 
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The  PLAN  type  is  viewed  as  a  special  kind  of  the  PRODUCT  type.  Thus,  Review 
Product  is  an  appropriate  process  requirement  to  apply  to  plans.  Plans  may  also  be 
regarded  as  embodying  other  artifacts  like  goals,  schedules,  processes,  requirements,  etc. 

4.3  Results 

4.3.1  Intermediate  Results. 

4. 3. 1.1  QAF  Criteria.  The  QAF  Criteria  are  made  up  of  7  Categories,  24 
Assessment  Items,  and  54  Areas  to  Address.  Functional  decomposition  of  the  QAF 
criteria  results  in  148  requirements.  Some  of  the  148  requirements  are  used  more  than 
once  to  provide  complete  coverage.  Consequently,  the  QAF  criteria  are  represented  by  a 
total  of  209  requirements.  The  exact  numbers  are  not  significant  since  different  analysts 
will  make  different  decisions  on  how  to  decompose  a  particular  English  paragraph.  The 
numbers  do  provide  general  insight  into  the  purpose  and  intended  use  of  the  model.  In 
the  QAF  criteria,  nearly  40  percent  of  the  148  requirements  involve  measuring  products 
and  processes,  analyzing  data,  evaluating  products  and  processes,  or  improving  them. 
Close  to  25  percent  of  the  distinct  requirements  correlate  to  the  Process  Management 
category  alone.  These  numbers  indicate  the  emphasis  the  QAF  criteria  places  on  process. 
About  15  percent  relate  to  the  customer,  and  another  7  percent  relate  to  the  supplier. 

4.3. 1.2  CMM.  The  CMM  is  comprised  of  18  Key  Process  Areas  and  150 
Activities  to  Perform,  along  with  practices  in  the  OCFs.  These  practices  are  broken  into 
190  requirements.  Many  of  the  190  requirements  are  used  more  than  once  to  provide 
complete  coverage.  Hence,  the  CMM  is  represented  by  a  total  of  350  requirements.  The 
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majority  of  the  repeat  process  requirements  involves  the  institutionalization  processes 
referenced  in  the  OCFs.  The  190  distinct  requirements  include  a  number  of  requirements 
addressing  the  same  processes,  but  from  the  different  perspectives  of  different  maturity 
levels.  This  dynamic  especially  occurs  in  the  areas  of  project  management,  process 
management  and  improvement,  quality  management  and  improvement,  and  data 
gathering  and  analysis. 

4.3.2  Final  Set  of  Integrated  Requirements.  The  following  paragraphs  discuss  the 
final  results  of  this  application  of  the  requirements  matching  approach.  The  final  set  of 
integrated  requirements  are  available  in  Appendix  A,  with  cross  references  in  Appendices 
B  through  E. 

4. 3. 2.1  Signature  Matching.  Most  of  the  comparisons  between  requirements 
are  performed  using  signature  matching  and  contextual  information.  As  mentioned  in 
Section  4.1.3,  signature  matching  is  most  efficiently  done  by  using  a  spreadsheet. 
Nonetheless,  it  is  important  to  recognize  what  operations  are  actually  being  performed. 
Recalling  Exact  Signature  Match  from  Section  3.4.1,  consider  Figures  9  and  10,  Measure 
Process  and  Collect  Measurement  Data,  respectively. 
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— MeasureProcess — 
Procreq 

Workers  :  P  Worker 


name  =  MeasureProcess 
id  =  AF-00J6 

correlates  =  {QAF-S.2,a,  QAF-S.3,b  } 

agents  =  {Workers} 

inputs  =  {(Process, PROCESS), 

(MeasurementPlan,PLAN), 
(ProcessIndicatorsJNDICATOR ) } 
outputs=  {(ProcessData,  DATA)} 
pre  =  0 
post  =  0 
subproc  —  0 


Figure  9  Requirement  to  Measure  Process. 


-—CollectMeasurementData- 

Procreq 

Collectors  :  P  Worker 


name  =  CollectMeasurementData 
id  =  AF~0366 

correlates  -  {CMM-QPAc4} 
agents  =  {Collectors} 

inputs  =  {(Process, PROCESS),  (QPMPlan,PLAN), 
(DatatoCollectJNDICATOR) 
outputs=  { (MeasurementData,DATA)} 
pre  =  0 
post  =  0 
subproc  =  0 


Figure  10  Requirement  to  Collect  Measurement  Data 

Figure  11  shows  that  by  simply  substituting  types  for  artifact  names,  a  comparison 
can  be  made  between  these  two  process  requirements  by  attempting  to  satisfy  the  axioms 
of  the  Exact  Signature  Match.  If  the  axioms  are  satisfied  resulting  in  a  final  result  of 
TRUE,  the  two  signatures  exactly  match.  The  two  process  may  be  redundant. 
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P ;  =  MeasureProcess 

P2  =  CollectMeasurementData 

MeasureProcess  esm  CollectMeasurementData  <=> 

ran  SQAReview. inputs  =  ran  CollectMeasurementData. inputs  a 
ran  SQAReview. outputs  =  ran  CollectMeasurementData.outputs 

MeasureProcess  esm  CollectMeasurementData  « 

(PROCESS, PLANJNDICATOR}  =  {  PROCESS J^LAN INDICATOR  } 

A  {  DATA  }  =  {DATA} 

MeasureProcess  esm  CollectMeasurementData  <=>  (TRUE  a  TRUE) 

MeasureProcess  esm  CollectMeasurementData  »  TRUE 

Figure  1 1  Application  of  Exact  Signature  Match 

Measure  Process  and  Collect  Measurement  Data  are  substituted  for  Pi  and  P2, 
respectively.  The  set  of  input  and  output  types  for  Measure  Process  are  compared  to 
those  of  Collect  Measurement  Data.  If  the  sets  are  equal,  Exact  Signature  Match  returns 
a  TRUE,  indicating  the  two  signature  have  identical  signatures.  It  is  important  to  note 
that  the  comparison  is  made  based  on  the  type  of  an  input  or  output,  rather  than  on  an 
arbitrary,  albeit  informative,  name. 

The  prior  example  explains  the  conceptual  foundation  for  matching  signatures. 
However,  since  the  majority  of  signature  matching  in  this  research  is  performed  using  a 
spreadsheet,  the  example  is  shown  again  using  the  spreadsheet.  Table  1  shows  a  partial 
listing  representing  the  signatures  of  Measure  Process  and  Collect  Measurement  Data,  as 
well  as  several  other  process  requirements  with  DATA  as  the  output  type.  (The  actual 
spreadsheet  includes  as  many  input  and  output  columns  as  needed.  For  this  research.  7 
input  and  3  output  columns  are  needed.  Other  fields  such  as  ID  number  are  also  helpful.  1 
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Name 

Input2 

Inputs 

Measure  Activity 

Indicator 

Plan 

Measure  Process 

Process 

Indicator 

Plan 

1^119^1 

Collect  Measurement  Data 

Process 

Indicator 

Plan 

Data 

Measure  Leader  Involvement 

Process 

Indicator 

Plan 

Data 

Analyze  OSSP 

Process 

Technology 

Data 

Gather  Product  Quality  Data 

Product 

Indicator 

Data 

Measure  Product  Quality 

Product 

Indicator 

Data 

Measure  Product 

Product 

Indicator 

Plan 

Data 

Gather  Service  Quality  Data 

Service 

Indicator 

Gather  Supplier  Data 

Source 

Indicator 

Gather  Financial  Data 

Source 

Indicator 

Data  1 

Table  I  Sample  Excel  Spreadsheet  of  Process  Requirement  Signatures. 


From  this  example,  it  is  easy  to  see  that  Measure  Process  and  Collect  Measurement  Data 
have  matching  signatures.  Additionally,  Measure  Leader  Involvement  is  identified  as  a 
candidate  for  matching  these  two  requirements.  Furthermore,  it  is  clear  Measure  Product 
Quality  and  Gather  Product  Quality  Data  are  partial  matches  with  Measure  Product.  A 
more  formal  presentation  of  Partial  Signature  Match  follows  in  Figures  12-14. 


—AnalyzeData - 

Procreq 

Workers  :  P  Worker 


name  -  AnalyzeData 
id  =  AF-00I6 

correlates  =  {QAF-2.2.a,  QAF-2.3.a,  QAF-2J.b,..,) 
agents  =  {Workers} 
inputs  =  {(Data,  DATA), 

(DataContext,  INFORMATION)} 
outputs=  { (DataAnalysis,  ANALYSIS)} 
pre  =  0 
post  =  0 
subproc  =  0 


Figure  12  Requirement  to  Analyze  Data 
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—AnalyzeQualityData- 

Procreq 

Workers  :  P  Worker 


name  =  AnalyzeQualityData 
id  =  AF-0352 

correlates  =  {CMM-PE.Mel,  CMM-SQ.Ac4} 
agents  —  {Workers} 
inputs  =  { (Data,  DATA), 

(DataContext,  INFORMATION), 

(Product,  PRODUCT),  (Quality Goals,  GOAL)} 
outputs=  {(ProductQuality Analysis,  ANALYSIS)} 
pre  =  0 
post  =  0 
subproc  =  0 


Figure  13  Requirement  to  Analyze  Quality  Data 


P I  =  AnalyzeData 

P2  —  AnalyzeQualityData 

AnalyzeData  psm  AnalyzeQualityData  e=> 

ran  SQAReview. inputs  c  ran  AnalyzeQualityData.inputs  a 
ran  SQAReview.outputs  c  ran  AnalyzeQualityData. outputs 

AnalyzeData  psm  AnalyzeQualityData  <=> 

{DATA,  INFORMATION}  c 

{DATA,  INFORMATION,  PRODUCT,  GOAL}  a 
{ANALYSIS}q  {ANALYSIS} 

AnalyzeData  psm  AnalyzeQualityData  «  (TRUE  a  TRUE) 
AnalyzeData  psm  AnalyzeQualityData  <=>  TRUE 


Figure  14  Application  of  Partial  Signature  Match. 

4.3.2.2  Specification  Matching.  Specification  matching  is  used  sparingly  in 

this  approach,  but  is  necessary  in  a  few  cases.  Specification  matching  is  performed 
manually,  much  in  the  way  it  is  presented  here  (other  than  signature  matching,  which  is 
performed  using  a  spreadsheet  as  described  in  the  last  section.) 
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Figures  15  and  16  contain  specifications  for  Develop  Training  Course  from  the 
CMM  and  Design  Training  from  the  QAF  criteria.  Even  though  the  Agents  do  not 
exactly  match.  Exact  Specification  Match  is  still  satisfied  as  seen  in  Figure  17.  Neither 
Exact  Specification  Match,  nor  Exact  Signature  Match  consider  Agents  for  a  match  since 
it  is  Agent  skills  that  are  important  and  not  the  name  attached  to  the  Agent.  Further 
discussion  of  this  point  is  in  Section  6.3.1. 


— DevelopTrainingCourse — 
Procreq 

Developers  :  P  Worker 
TrainingGroup  :  P  Worker 


name  =  DevelopTrainingCourse 
id  =  AF-0304 

correlates  =  {CMM-TP  .Ac4} 
agents  =  (Developers,  TrainingGroup} 
inputs  =  { (OrgTrainingPlan,  PLAN), 
(TrainingNeeds,  REQ)} 
outputs  =  { (TrainingCourse,  COURSE)} 
pre  =  0 

post  =  MEETS  (TrainingCourse,  TrainingNeeds) 
subproc  =  0 


Figure  15  Requirement  to  Develop  Training  Course 
In  Figure  17,  the  Exact  Specification  Match  is  applied  to  Develop  Training  Course 
and  Design  Training.  Exact  Signature  Match  is  applied  to  ensure  the  signatures  match 
and  the  pre-conditions  and  post-conditions  of  each  requirement  are  compared  to  ensure 
they  are  equivalent.  Moreover,  any  sub-processes  of  the  two  requirements  are  required  to 
be  equal  for  an  exact  specification  match. 
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— DesignTraining - 

Procreq 

Designers  :  P  Worker 


name  =  DesignTraining 
id  =  AF-0082 
correlates  =  {QAF-4.3.b} 
agents  =  {Designers} 

inputs  =  {(TrainingPlan,  PLAN),(TrainingNeeds,  REQ) 
outputs  —  { (TrainingCourse,  COURSE)} 
pre  =  0 

post  =  MEETS  (TrainingCourse,  TrainingNeeds) 
subproc  =  0 


Figure  16  Requirement  to  Design  Training. 


P  j  =  DevelopTrainingCourse 
P2  =  DesignTraining 

DevelopTrainingCourse  espm  DesignTraining  o 

DevelopTrainingCourse  esm  DesignTraining  <=> 

(ran  DevelopTrainingCourse. inputs  =  ran 
DesignTraining.inputs  a 

ran  DevelopTrainingCourse. outputs  =  ran 
DesignTraining.outputs  )  a 

DevelopTrainingCourse. pre  <=>  DesignTraining.pre  a 
DevelopTrainingCourse. post  <=>  DesignTraining.post  a 
DevelopTrainingCourse.subproc  =  DesignTraining.subproc 

DevelopTrainingCourse  espm  DesignTraining  « 

DevelopTrainingCourse  esm  DesignTraining  <t=> 

({PLAN,  REQ}  =  {PLAN,  REQ}  a 
{COURSE}  =  {COURSE}  )  a 
TRUE  «>  TRUE  a 

Meets (COURSEMQ)  <=>  Meets  (COURSE, REQ) 

0  =  0 

DevelopTrainingCourse  espm  DesignTraining  <=» 

DevelopTrainingCourse  esm  DesignTraining  <=>  (TRUE  aTRUE)  a 
TRUE  A  TRUE  a  TRUE 

DevelopTrainingCourse  espm  DesignTraining  TRUE  a  TRUE 

DevelopTrainingCourse  espm  DesignTraining  TRUE _ 

Figure  17  Application  of  Exact  Specification  Match. 
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Figures  18-20  show  an  example  of  the  Partial  Specification  Match. 


—IndependentSQAReview- 

Procreq 

SQAGroup  :  P  Worker 


name  =  IndependentSQAReview 
id  =  AF-0274 
correlates  =  {QAAclO} 
agents  =  {Reviewers} 
inputs  =  {(SQAActivities,  ACTIVITY), 
(IndependentSQAPlan,  PLAN), 
(ReviewCriteria,  CRITERIA)} 
outputs=  { (SQAActionItems,  ACTION), 

(Report,  INFORMATION)} 
pre  =  {[agents  n  SQAGroup  -  0] } 
post  =  {[^Meets(SQAActivities,  ReviewCriteria) 
=>  SQAActionItems  1^0]} 
subproc  -  {Document (SQAActionItems)} 


Figure  18  Requirement  for  Independent  SQA  Review. 


r-SQAReview- 

Procreq 


name  =  SQAReview 
id  =  AF-0205 
correlates  =  {QAAc4} 
agents  =  {SQAGroup} 
inputs  =  {(ProjectActivities,  ACTIVITY), 
(SQAPlan,PLAN), 

(ReviewCriteria,  CRITERIA) 
outputs=  { (CorrectiveActions,ACTION), 
(ReportJNFORMATION) } 
pre  =  0 

post  =  {l^Meets(ProJectActivities, ReviewCriteria) 
==>  CorrectiveActions  ^  0]} 
subproc  =  {Document(CorrectiveActions)} 


Figure  19  Requirement  for  SQA  Review 
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As  seen  here  in  Figure  20,  Partial  Specification  Match  is  applied  to  SQA  Review  and 


Independent  SQA  Review. 


P I  =  SQAReview 

P2  =  IndependentSQAReview 

SQAReview  pspm  IndependentSQAReview  o 

SQAReview  psm  IndependentSQAReview  <=> 

(ran  SQAReview. inputs  c  ran  IndependentSQAReview. inputs  a 
ran  SQAReview. outputs  c  ran  IndependentSQAReview. outputs ) 

A 

SQAReview. pre  =>  IndependentSQAReview.pre  a 
IndependentSQAReview. post  =>  SQAReview. post  a 
SQAReview. subproc  c  IndependentSQAReview. subproc 

SQAReview  pspm  IndependentSQAReview 

SQAReview  psm  IndependentSQAReview  <=> 

({ACTIVITY,  PLAN,  CRITERIA}  c  {ACTIVITY,  PLAN,  CRITERIA}  a 
{ACTION,  INFORMATION}  c  {ACTION,  INFORMATION}  a 
TRUE  (GROUP  n  GROUP  =  0)  a 
(^Meets(ACTIVITY,  CRITERIA)  =>  ACTION  ^  0) 

(-’Meets (ACTIVITY,  CRITERIA)  =>  ACTION  ^  0) 

Document  (ACTION)  c  Document  (ACTION) 

SQAReview  pspm  IndependentSQAReview  <=> 

SQAReview  psm  IndependentSQAReview  <=>  (TRUE  a  TRUE )  a 
TRUE  A  TRUE  A  TRUE 

SQAReview  pspm  IndependentSQAReview  <=>  TRUE  a  TRUE 
SQAReview  pspm  IndependentSQAReview  <=>  TRUE 


Figure  20  Application  of  Partial  Specification  Match. 

For  a  successful  match,  SQA  Review  must  be  more  specific  than  (or  equivalent  to) 
Independent  SQA  Review.  In  other  words,  the  signature  of  SQA  Review  must  be  equal  to, 
or  a  subset  of,  the  signature  of  Independent  SQA  Review.  The  pre-conditions  of  SQA 
Review  must  imply  the  pre-conditions  of  Independent  SQA  Review  and  the  post¬ 
conditions  of  Independent  SQA  Review  must  imply  the  post-conditions  of  SQA  Review. 
Finally,  the  sub-processes  of  SQA  Review  must  be  equal  to,  or  a  subset  of,  the  sub- 
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processes  of  Independent  SQA  Review.  It  is  important  to  note  that  Partial  Specification 
Match  also  returns  TRUE,  indicating  a  match,  for  two  requirements  with  signatures 
satisfying  Partial  Signature  Match  (but  not  Exact  Signature  Match)  and  specifications  that 
are  equivalent. 

4. 3.2.3  Final  Results.  The  final  set  of  integrated  requirements  consists  of  196 
distinct  process  requirements.  Of  these,  82  are  uniquely  correlated  to  the  CMM,  7 1  are 
uniquely  correlated  to  the  QAF  criteria,  and  43,  or  about  22  percent,  are  correlated  to  both 
models.  At  first  glance,  these  numbers  seem  to  indicate  a  significant,  but  not 
overwhelming,  relationship  between  the  two  models.  However,  this  viewpoint  is 
misleading.  A  better  measure  of  the  relationship  depends  on  the  number  of  QAF 
requirements  that  relate  to  CMM  requirements  and  vice  versa.  Using  this  measure,  43  out 
of  54,  or  nearly  80  percent,  of  the  QAF  Areas  to  Address  relate  to  CMM  practices,  while 
90  out  150,  or  60  percent  of  the  CMM  practices  relate  to  QAF  Areas  to  Address.  (This 
does  not  include  practices  in  the  Other  Common  Features.)  The  more  important 
relationships  are  discussed  in  Section  6. 1 . 
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V.  Verification  and  Application 


5.1  Verification 

In  developing  software,  it  is  important  to  ensure  each  transformation  from 
requirements  to  design  to  implementation  is  accurate.  In  this  research,  there  are  two 
major  transformation  steps.  The  first  transformation  involves  decomposing  CMM  and 
QAF  requirements  into  low-level  requirements.  The  second  transformation  involves 
integrating  these  low-level  requirements  into  a  single  set.  As  in  software  development, 
each  of  these  transformations  are  verified. 

5.1.1  Decomposed  Requirements.  The  verification  for  this  step  is  twofold.  One 
part  of  the  verification  is  to  ensure  each  element  of  the  CMM  and  QAF  criteria  are 
represented  in  the  respective  set  of  low-level  requirements.  This  check  is  facilitated  by  a 
cross-reference  similar  to  Appendix  D  or  E.  The  second  part  of  the  verification  is  to 
ensure  each  low-level  requirement,  or  group  of  requirements,  accurately  defines  the 
respective  component  from  the  CMM  or  QAF  criteria.  Ideally,  this  is  accomplished  by 
someone  other  than  the  one  who  performed  the  decomposition.  In  this  effort,  this  is 
accomplished  by  the  researcher. 

5.1.2  Integrated  Requirements.  After  integrating  the  requirements,  it  is  important  to 
assure  the  completeness  of  the  integrated  set.  Appendices  B  and  C  are  cross-references 
providing  this  assurance.  Another  important  part  of  verifying  the  integrated  set  relates  to 
compatibility.  The  assumption  is  the  two  models  are  compatible,  thus  the  integrated  set 
should  represent  a  set  of  processes  that  can  be  composed  together  to  form  systems.  For 
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example,  the  process  improvement  system  is  composed  of  several  processes  meeting  the 
requirements  given  in  the  integrated  set.  Figure  2 1  shows  how  these  processes  might  be 
put  together  to  create  a  process  improvement  system  in  the  organization. 


Process  Data 


Pilot  Process 

[Design 

Improvement 

Review  Product 

0186 

- - 

New 

XProcess 

0108 

Process 


Implement  Process 
0187 

Revise  PDSP 

0131 

Maintain  OSSP 
0192 

I 


New  PDSP 


3 


New  OSSP 


PDSP 


OSSP 


Figure  21  Composition  of  Processes  to  Form  a  Process  Improvement  System. 


This  example  also  illustrates  the  essence  of  an  organization’s  Process  Asset  Library 
(PAL).  The  PAL  is  essentially  a  reuse  library  for  process  components.  For  a  particular 
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application,  the  user  simply  identifies  process  components  that  meet  requirements,  and 
composes  them  into  processes  or  systems. 

5.2  Application 

5.2.1  Overview  of  SSG’s  Systems  Engineering  Process  (SEP).  The  SEP  is  a 
description  of  the  processes  used  by  the  Standard  Systems  Group  (SSG)  to  produce 
software  systems.  ^  In  terms  of  the  CMM,  it  is  the  Organization  Standard  Software 
Process,  or  OSSP.  It  describes  the  system  lifecycle  and  provides  templates  and  tailoring 
guidelines  for  users.  In  terms  of  the  QAF  Criteria,  it  contains  the  designs  of  the  various 
production  and  support  processes. 

The  SEP  is  divided  into  three  phases,  designated  as  Pre-Development, 
Development,  and  Post-Development.  These  phases  are  subdivided  into  nine  processes. 
The  Development  phase  consists  of  five  processes,  while  the  other  two  phases  have  two 
processes  each.  Each  process  is  composed  of  four  stages;  Perform  Activity,  Work 
Review,  Update  Project  Indicators,  and  Management  Review.  These  four  stages  are 
common  to  all  nine  processes  across  all  three  phases.  The  stages  are  broken  into 
activities,  tasks,  and  procedures,  with  activities  the  most  general  and  procedures  the  most 
specific  [STAN96].  The  requirements  from  the  CMM  and  QAF  Criteria  are  generally  at 
the  activity  or  task  level.  The  SEP  does  not  explicitly  identify  linkage  to  either  model. 

5.2.2  Applying  the  Integrated  Set  of  Requirements  to  the  SEP.  In  software 
development,  the  design  phase  begins  after  sufficiently  describing  the  problem  domain 
and  restricting  the  solution  space.  With  the  integrated  set  of  process  requirements, 
process  design  may  begin.  However,  in  this  application  the  SEP,  or  the  process  design. 
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already  exists.  Therefore,  the  integrated  requirements  are  compared  to  the  SEP  to  identify 
linkage  from  the  SEP  to  either  of  the  models  through  the  integrated  set.  A  sample  of  this 
comparison  is  provided  in  Table  2  on  the  following  page.  Each  reference  from  the  SEP  is 
mapped  to  a  process  requirement  from  the  integrated  set  and  the  appropriate  linkage  to 
the  models.  The  mapping  is  not  accomplished  by  matching  signatures  or  specifications 
since  the  SEP  does  not  give  inputs  and  outputs  at  the  activity  and  task  levels.  Instead,  the 
mapping  is  performed  by  using  the  integrated  requirement  information  given  in  the 
framework,  and  comparing  it  to  the  activities,  tasks,  and  procedures  specified  in  the  SEP. 
Some  SEP  requirements,  such  as  Negotiate  Estimates  with  Group(s)  and  Create  Project 
Plan,  map  very  closely  to  the  related  integrated  requirements.  Other  requirements  in  the 
SEP,  like  Analyze  CSRD  and  Level  of  Effort  Baseline,  are  more  specific  than  the 
integrated  requirements.  This  is  to  be  expected,  since  the  integrated  requirements,  like 
the  models  from  which  are  derived,  are  meant  to  be  general,  reusable  requirements  that 
are  applied  as  needed  throughout  the  organization.  Additionally,  as  addressed  in  Section 
1.5.3,  there  may  be  requirements  for  activities,  tasks,  or  procedures  in  the  SEP  that  are 
not  linked  to  any  requirement  in  the  integrated  set. 
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SEP  Reference 

Linkage 

ID 

Level 

4.1.1  Needs  Analysis:  Perform 
Activity 

Analyze  CSRD 

RM.Acl,  RM.Ac3,  PE.Ac2 

AF-0149 

Task 

Level  of  Effort  Baseline 

Ab 

AF-0055 

Task 

POM/Funding  Documentation 

Ab 

AF-0056 

Task 

4.1.2  Needs  Analysis  Work 

Review 

Review  Preparation 

PR.Acl 

Elailual 

Analyze  CSRD 

RM.Acl,  RM.Ac3,  PE.Ac2 

AF-0149 

Task 

Review  Follow-up 

Task 

4.2.1  Project  Planning:  Perform 
Activity 

Complete  SEP  Tailoring 
Worksheet 

QA.Ac3,  PF.Ac3,  IM.Acl, 
PE.Acl 

AF-0130 

Task 

Develop  Estimates  and 
Schedules 

PP.AclO,  PP.AclS,  PF.Ac4, 
IM.Ac4,  IM.AcS,  IM.Ac7 

AF-0134 

Task 

Develop  Estimates  and 
Schedules 

PP.AclO,  PP.AclS,  PF.Ac4, 
IM.Ac4,  IM.Ac5,  IM.Ac7 

AF-0135 

Task 

Develop  Estimates  and 
Schedules 

PP.Acl2,  PP.AclS,  PF.Ac4, 
IM.Ac4,  IM.Ac5,  IM.Ac9 

AF-0137 

Act 

Negotiate  estimates  with 
group(s) 

PF.Co2,  PF.Co3,  PF.Ac4, 
PD.Ac5 

AF-0111 

Task 

Create  Project  Plans 

5.1.a,  5.2.a,  5.3.b,  PP.Ac2, 
PP.Ac3,  PP.Ac5,  PP.Ac6, 
PP.Ac7,  PP.Acl4,  PT.Acl, 
PT.Ac2,  QA.Acl,  QA.Ac3, 
CM.Acl,TP.Acl,IM.Ac3, 
IM.Ac4,  IM.Ac5,  IC.Ac3, 
IC.Ac4,  QP.AcLSQ.Acl, 
DP.Acl 

AF-0114 

Act 

Project  Level  Training  Plan 

4.3.b,  TP.Acl 

AF-0089 

Task 

Test  and  Evaluation  Master 
Plan 

PE.Ac7 

AF-0161 

Task 

4.2.3  Project  Planning:  Update 
Project  Indicators 

Number  of  man-hours 
expended 

Me,  PT.Acll 

AF-0110 

M 

Table  2  Sample  Mapping  of  SEP  to  Integrated  Requirements. 
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The  Standard  Systems  Group,  or  any  other  Air  Force  software  organization,  can  use 
the  integrated  set  of  requirements  to  determine  what  processes  it  needs  in  it  OSSP  to 
satisfy  both  the  CMM  and  QAF  Criteria.  The  requirements  are  mapped  back  to  each 
model,  so  the  organization  is  able  to  refer  the  model  to  understand  the  context  and 
subtleties  of  a  process  that  would  satisfy  a  particular  requirement.  Thus  there  may  be 
multiple  variations  of  any  particular  process.  The  integrated  set  of  process  requirements, 
along  with  the  two  models,  provide  the  basis  for  designing  or  acquiring  organizational 
processes. 
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VI.  Conclusions,  Generalization,  and  Recommendations 


6.1  Conclusions 

The  overall  goal  of  this  research  is  to  integrate  the  CMM  and  QAF  criteria.  The 
successful  accomplishment  of  this  goal  is  represented  by  the  integrated  set  of 
requirements  in  Appendix  A  and  the  associated  cross-references  in  Appendices  B-E.  The 
successful  integration  of  the  two  models  represents  a  42%  reduction  in  the  number  of 
requirements  an  organization  must  manage  and  meet.  This  reduction  translates  into  a 
large  savings  in  the  staffing  and  resources  needed  to  design,  implement,  and  manage  the 
processes  required  to  satisfy  the  two  models. 

Intuitively,  the  two  models  fit  together  well  since  they  are  both  based  on  the  same 
quality  principles.  As  the  42%  reduction  shows,  the  two  models  are,  in  fact,  strongly 
linked.  As  noted  in  Section  4.3.2.3,  nearly  80  percent  of  the  QAF  criteria  relate  to  CMM 
practices,  and  about  60  percent  of  the  CMM  relates  to  QAF  Areas  to  Address.  This 
should  not  be  too  surprising  a  result,  since  the  QAF  criteria  is  meant  to  be  applied  to  a 
wide  range  of  businesses.  The  CMM,  on  the  other  hand,  pertains  specifically  to  software, 
and  thus  contains  many  practices  that  are  too  domain-specific  to  appear  in  the  QAF 
criteria.  One  example  is  the  requirement  to  Develop  Software  Code.  This  requirement 
obviously  does  not  appear  in  the  QAF  criteria.  Removing  this  type  of  domain-specific 
requirement  increases  the  CMM-to-QAF  linkage  to  70  percent. 
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Some  of  the  relationships  consist  of  using  the  same  process  for  different  purposes. 
For  instance,  the  Strategic  Planning  requirement  calls  for  a  planning  process  for  any 
strategic  level  plans,  such  as  the  organization’s  business  plans,  process  improvement 
plans,  or  human  resource  plans.  Although  some  relationships  fall  into  this  category,  most 
are  much  more  direct.  The  Identify  Training  Needs  requirements  is  a  one-to-one 
relationship  between  a  requirement  in  the  CMM  (TP.Acl)  and  the  QAF  criteria  (4.3.b). 

In  addition  to  these  direct  relationships,  there  are  also  implicit  relationships  among 
many  of  the  Assessment  Items  in  the  QAF  criteria  and  practices  or  Key  Process  Areas  in 
the  CMM.  The  more  important  relationships  are  expounded  below. 

6.1.1  Process  Management.  The  strongest  relationship  between  the  two  models 
emphasizes  the  process.  Category  5.0  of  the  QAF  criteria  concerns  managing-evaluating 
and  improving— production,  support,  and  supplier  processes.  The  CMM  also  accentuates 
the  importance  of  this  concept.  Organization  Process  Focus  (PF),  Organization  Process 
Definition  (PD),  Quantitative  Process  Management  (QP),  and  Process  Change 
Management  (PC)  all  relate  to  managing  processes.  Nearly  all  the  practices  in  these  key 
process  areas  of  the  CMM  are  correlated  to  areas  in  the  QAF.  The  converse  is  true  for  the 
QAF  criteria.  One  place  this  is  especially  evident  is  the  software  process  improvement 
example  shown  in  Figure  21  of  Section  5.1.2.  This  system  consists  of  18  process 
requirements,  1 1  from  both  models,  4  from  the  CMM,  and  3  from  the  QAF  criteria. 

Another  strong,  process-related  relationship  between  the  models  concerns 
institutionalizing  processes  in  the  organization.  The  CMM  addresses  this  aspect  through 
OCFs  by  requiring  policies  and  standards,  adequate  resources,  measurement  and  analysis. 
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and  verification  by  senior  leaders  and  quality  assurance.  The  QAF  criteria  addresses 
institutionalization  by  requiring  data  collection,  review,  and  improvement  cycles. 

6.1.2  Training.  Training  is  another  strong  link  between  the  two  models.  Category 
4.0  of  the  QAF  criteria  address  human  resources.  One  aspect  crucial  to  the  development 
of  human  resources  is  training.  Item  4.3  of  the  QAF  criteria  specifically  addresses  the 
training  aspect.  The  CMM  does  not  extend  beyond  training  in  the  Human  Resource 
realm,  but  the  Training  Program  (TP)  ties  tightly  to  the  Areas  to  Address  in  the  QAF 
criteria.  This  linkage,  in  addition  to  the  process  management  linkage,  shows  the 
importance  both  models  place  on  building  infrastructure  throughout  the  organization. 

6.1.3  Supplier  Management.  A  somewhat  surprising  linkage  between  the  two 
models  relates  to  managing  suppliers.  The  CMM  refers  to  this  as  Subcontractor 
Management  (SM),  but  there  is  also  some  linkage  in  the  InterGroup  Coordination  (IC) 
key  process  area.  Many  software  organizations  in  the  Air  Force  have  trouble  relating  the 
SM  key  process  area  to  its  processes.  In  fact,  in  software  assessments,  SM  is  often 
considered  to  be  “not  applicable.”  Viewing  these  practices  as  supplier  processes  from  the 
perspective  of  the  QAF  criteria,  it  is  clearly  applicable  to  all  Air  Force  software 
organizations.  There  are  also  references  to  internal  suppliers  in  the  IC  key  process  area. 
These  also  are  applicable  to  the  QAF  Item  5.4. 

6.1.4  Data  Gathering.  Data  gathering  and  measurement  are  addressed  in  very 
general  terms  in  both  models.  This  is  due  to  their  non-prescriptive  natures.  Each  model 
tries  to  guide  the  organization  to  make  informed  decisions  about  what  to  measure  and 
why.  The  linkage  between  the  two  models  in  this  area  is  fairly  strong.  Both  models 
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identify  the  kind  of  measurements  to  make  and  give  guidance  on  what  to  do  with  the  data. 
Specifically,  the  Gather  Internal  Data  requirement  from  the  QAP  criteria  and  the 
Maintain  Process  Database  requirement  from  the  CMM  call  for  the  organization  to 
collect  data  from  across  the  organization  to  gain  an  organizational  perspective.  This 
perspective  is  explicitly  called  for  by  the  QAF  criteria  in  Item  1.2,  and  implicitly  in  the 
CMM  in  the  Process  Definition  and  Process  Change  key  process  areas. 

6.1.5  Plans.  One  area  that  is  not  so  clear  pertains  to  plans.  The  CMM  is  rife  with 
requirements  for  informal  and  formal  plans.  The  essence  is  to  “plan  the  work  and  work 
the  plan.”  However,  the  sheer  number  of  plans  is  quite  large.  In  the  QAF  Criteria,  the 
verbiage  leads  the  organization  to  place  more  focus  on  the  planning  process  rather  than 
the  output  plan.  In  any  case,  it  is  a  matter  of  judgment  for  the  organization  to  determine 
which  plans  are  necessary  and  which  are  of  little  or  no  value.  In  the  integrated  set  of 
requirements,  there  are  two  major  planning  requirements.  Strategic  Planning  and  Project 
Planning,  in  addition  to  several  other  more  specific  requirements  such  as  Plan 
Community  Involvement  and  Develop  Software  Risk  Management  Plan. 

6.2  Generalization 

This  approach  may  be  used  to  integrate  any  kind  of  requirements,  including  software 
requirements  and  security  requirements.  Formally  specified  software  requirements  may 
be  integrated  using  the  signature  and  specification  matching  of  this  approach.  Just  like 
examples  given  by  Zaremski  [ZARE95a,  ZARE95b]  for  software  code  components,  any 
software  requirements  may  be  matched  to  ensure  consistency  and  eliminate  redundancy. 


70 


Security  requirements  are  often  a  concern  in  military  systems.  These  requirements 
can  be  integrated  along  with  other  requirements  to  ensure  a  software  system  completely 
addresses  software  requirements,  as  well  as  security  requirements.  A  possible  place  of 
application  would  be  in  comparing  security  requirements  to  configuration  management 
requirements.  Configuration  management  involves  controlling  access,  which  security  for 
software  systems  also  addresses.  This  approach  would  ensure  both  sets  of  requirements 
are  addressed  while  eliminating  redundancy. 

63  Recommendations 

63.1  Use  Object  Modeling  Technique  (OMT).  One  very  promising  avenue  for 
extending  this  approach  relies  on  the  object  modeling  technique  (OMT)  espoused  by 
Rumbaugh  [RUMB91].  OMT  is  an  object-oriented  method  for  analyzing,  designing,  and 
implementing  software  systems.  The  following  sections  describe  how  the  results  of  this 
approach  relate  OMT,  in  general,  and  how  they  specifically  relate  to  the  Hibdon  model 
mentioned  in  Section  4. 1 .4. 

6.3. 1.1  Relationship  to  OMT.  The  process  requirements  that  result  from  this 
approach  are  easily  modeled  using  Rumbaugh’s  OMT.  Each  particular  process 
requirement  is  an  instance  of  the  process  requirement  class.  Requirements  can  be 
aggregated  together,  as  appropriate,  to  form  the  key  requirements  for  projects,  sub¬ 
systems,  or  whole  organizations.  The  software  process  improvement  sub-system  shown 
in  Figure  21  is  an  excellent  example.  The  process  requirements,  i.e.,  process  objects,  are 


71 


composed  together  to  form  the  fundamental  requirements  for  the  software  process 
improvement  sub-system. 

Process  objects  can  be  aggregates  of  sub-processes,  tasks,  or  procedures.  Special 
relationships  between  process  requirements,  such  as  those  between  Measure  Process  and 
Evaluate  Process  can  be  shown  explicitly  in  the  OMT.  Furthermore,  other  objects 
needed  to  model  an  organization,  such  as  people  and  tools,  can  be  included  in  the  model 
along  with  relationships  to  the  process  requirement  objects.  This  is  the  type  of  model 
Hibdon  uses  to  represent  and  Air  Force  wing  [HIBD95]. 

6. 3. 1.2  Relationship  to  Hibdon’ s  Model.  Hibdon  uses  OMT  to  create  an 
organizational  model  of  an  Air  Force  wing,  and  then  goes  on  to  describe  how  the  model  is 
generalized  to  most  any  type  of  organization.  His  model  consists  of  a  ToolSet,  a 
ManningPlan,  a  Workforce,  and  any  number  of  Projects  [HIBD95],  which  agrees  closely 
with  the  Software  Engineering  Institute’s  view  of  a  software  organization  consisting  of 
people,  process,  and  technology  integrated  into  a  system  to  produce  software  [NEXT92]. 
Thus  Hibdon’s  model  may  be  used  to  provide  an  infrastructure  to  compose  the  integrated 
set  of  requirements  into  a  full-blown  organization  with  a  variety  of  projects  and  sub¬ 
systems,  as  described  in  the  previous  section.  The  following  paragraph  describes  some  of 
the  relationships  between  Hibdon’s  model  and  the  integrated  set  of  requirements. 

Hibdon  identifies  the  most  basic  objects  in  his  model  as  Tool,  Worker,  Position,  and 
Job,  [HIBD95].  No  specific  tools  are  addressed  in  the  integrated  set;  however,  there  are 
requirements  that  relate  to  measuring,  evaluating,  and  improving  technology  in  the 
project  or  organization.  Requirements  like  Identify  Technology  Change  Areas  would 
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operate  on  the  Tool  object  or  the  ToolSet  that  contains  it.  Similarly,  there  are 
requirements  that  would  operate  on  the  Worker  object  such  as  Evaluate  Member,  and  one 
that  would  operate  on  the  Workforce  object  such  as  Assess  Workforce  Motivation.  The 
Position  object  relates  closely  to  the  Agent  field  in  the  integrated  set.  The  Agent  field  is 
identifies  roles  needed  for  a  particular  task,  and  the  Position  object  likewise  identifies  the 
skills  a  particular  worker  has.  The  qualified_for  association  in  Hibdon’s  model  provides 
the  linkage  between  these  two  concepts,  although  the  association  is  between  a  Worker  and 
a  Job.  The  Job  object  is  at  a  lower  level  of  detail  than  any  of  the  process  requirements. 
The  process  requirements  relate  more  closely  to  the  Task  object,  but  do  have  some 
relationship  the  Job  object,  as  seen  in  the  last  paragraph.  Even  though  Hibdon’s  model 
fits  very  well  with  the  integrated  requirements,  the  exact  nature  of  the  many  relationships 
and  their  implementations  in  an  executable  model  need  more  in-depth  study  to  determine 
the  plausibility  and  benefits  of  modeling  a  software  organization  in  this  manner. 

6.3.2  Process  Asset  Library  (PAL).  As  mentioned  earlier,  the  process  asset  library, 
or  PAL,  is  a  repository  for  process  assets  of  the  organization.  It  is  essentially  the  same  as 
a  component  library  for  software  components.  If  processes  are  formally  specified,  then 
signature  and  specification  matching  can  be  used  to  identify  and  retrieve  required 
processes  from  the  PAL.  The  concept  behind  the  CMM’s  Organization’s  Standard 
Software  Process  (OSSP)  and  Project’s  Defined  Software  Process  (PDSP)  is  the  same  as 
the  PAL.  The  OSSP  is  the  library  of  processes  for  a  project  to  choose  and  use.  Using 
tailoring  guidelines  provided  in  the  OSSP,  the  project  manager  selects  process 
components  to  compose  into  the  PDSP.  Signature  and  specification  matching  provide  a 
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robust  search  engine  for  identifying  and  retrieving  the  needed  process  components. 
Further  research  into  an  Air  Force-wide  PAL  with  search  and  retrieval  capabilities  is 
recommended. 

6.3.3  Study  Data  Requirements.  The  requirements  for  collecting  and  analyzing  data 
in  both  models  are  a  point  for  further  study.  As  related  to  this  research,  the  data 
requirements  for  an  organization  can  be  determined  and  compared  to  guidelines  such  as 
the  Software  Engineering  Institute’s  core  measures  or  the  Air  Force  core  measures. 
These  measures  give  context  for  requirements  to  identify  what  to  measure,  when,  and 
how.  By  using  the  integrated  set  of  requirements  in  concert  with  this  guidance.  Air  Force 
organizations  may  more  easily  determine  their  key  performance  drivers,  the  indicators  to 
measure  them,  and  the  objectives  they  want  to  obtain. 

6.4  Final  Comments 

This  research  successfully  demonstrates  signature  and  specification  matching  to 
integrate  the  CMM  and  the  Quality  Air  Force  criteria.  Appendix  A  contains  a  set  of 
requirements  integrated  from  the  two  models  and  correlated  back  to  the  source  for 
reference  purposes.  This  research  shows  that  the  CMM  and  QAF  criteria  complement 
and  support  each  other  in  concept  and  in  application.  Air  Force  software  organizations 
may  use  the  appendices  to  this  document  as  resources  to  determine  which  requirements 
they  satisfy  and  which  they  are  missing.  By  using  these  resources  as  the  basis  for 
designing  organization  processes.  Air  Force  software  organizations  eliminate  redundant 
efforts  and  save  resources,  funding,  and  staffing. 
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Appendix  A  -  Integrated  Set  of  Process  Requirements 


1.0  Purpose 

The  overall  purpose  of  this  document  is  to  provide  a  set  of  process  requirements 
completely  representing  the  key  requirements  specified  by  the  Capability  Maturity  Model 
for  Software  (CMM)  and  the  Quality  Air  Force  (QAF)  criteria. 

2.0  Overview 


This  document  contains  196  process  requirements  obtained  from  the  CMM  and 
QAF  criteria.  These  process  requirements  represent  all  the  key  requirements  specified  in 
both  models.  This  set  of  requirements  is  derived  by  functionally  decomposing  each 
model  into  low-level  requirements,  comparing  the  requirements  to  each  other  based  on 
signatures  and  specifications,  and  eliminating  redundancies  by  integrating  matching 
requirements  into  single  representative  requirements.  Most  matches  are  identified  by 
matching  signatures,  or  input/output  types,  while  some  are  identified  by  matching 
specifications,  or  pre-conditions  and  post-conditions. 

Each  process  requirement  is  presented  in  a  framework  as  shown  below: 


Name  Descriptive  name  of  the  process  requirement. 

ID  Arbitrary  identification  number  assigned  as  part  of  managing  the  requirements. 

Purpose  Brief  description  of  the  purpose  of  the  process  requirement. 

Correlates  to  Code  correlating  the  process  requirement  back  to  one  of  the  original  models,  i.e., 
the  CMM  or  QAF  criteria.  The  code  key  is  given  in  Section  4. 

Agents  Descriptive  name(s)  of  people  who  perform,  control,  or  act  in  the  process. 

Inputs  Descriptive  name(s)  of  process  artifacts  needed  to  conduct  the  process. 

Outputs  Descriptive  name(s)  of  process  artifacts  produced  by  the  process. 

Entrance  Pre-conditions  that  must  exist  before  the  process  can  begin  and  be  successfully 
Criteria  performed. 

Exit  Criteria  Post-conditions  that  must  exist  for  the  process  to  have  finished  successfully. 
Comments  Explanatory  remarks  to  better  understand  the  process  requirement  and  its  use. 
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3.0  Intended  Use 


The  intended  use  of  this  document  is  as  a  reference  for  Air  Force  software 
organizations  to  definitively  determine  if  they  are  addressing  and  meeting  the  process 
requirements  specified  by  both  the  CMM  and  QAF  criteria.  It  is  not  meant  to  replace  or 
supplant  either  model,  but  rather  to  supplement  and  complement  both  of  the  models. 
Toward  that  end,  this  document  should  be  used  in  conjunction  with  the  following 
associated  documents: 

Appendix  B  Capability  Maturity  Model  Relations  to  Quality  Air  Force  and 
Integrated  Requirements 

Appendix  C  Quality  Air  Force  Relations  to  Capability  Maturity  Model  and 
Integrated  Requirements 

Appendix  D  Capability  Maturity  Model  Map  to  Integrated  Requirements 

Appendix  E  Quality  Air  Force  Criteria  Map  to  Integrated  Requirements 

These  are  quick-reference  mappings  of  the  two  models  to  each  other  and  to  the  integrated 
set  of  requirements  contained  in  this  document.  This  set  of  five  documents  may  be  used 
in  a  variety  of  fashions.  The  following  paragraphs  give  a  brief  description  of  a  few 
possible  uses. 

3.1  Start  with  the  Integrated  Set.  An  organization  may  start  with  this  document 
containing  the  integrated  set  of  requirements.  Using  the  index,  the  organization  is  able  to 
identify  categories  of  requirements  such  as  those  related  to  evaluating  processes  or 
products,  and  locate  requirements  fitting  that  category.  These  requirements  may  be 
mapped  back  to  the  CMM  or  QAF  criteria  to  determine  which  activities  or  areas  are  met. 

3.2  Start  with  the  CMM.  An  organization  may  start  with  the  CMM  as  the  source  ot 
requirements  for  its  software  process  and  may  begin  implementing  processes  to  moot 
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those  requirements.  Using  Appendix  B,  Capability  Maturity  Model  Relations  to  Quality 
Air  Force  and  Integrated  Requirements,  and  Appendix  D,  Capability  Maturity  Model 
Map  to  Integrated  Requirements,  the  organization  is  able  to  identify  the  requirements  in 
the  QAF  criteria  that  it  has  met,  as  well  as  the  ones  it  has  not  met. 

3.3  Start  with  the  QAF  Criteria.  An  organization  may  start  with  the  QAF  criteria  as 
the  source  of  requirements  for  its  software  process  and  may  begin  implementing 
processes  to  meet  those  requirements.  Using  Appendix  C,  Quality  Air  Force  Relations  to 
Capability  Maturity  Model  and  Integrated  Requirements,  and  Appendix  E,  Quality  Air 
Force  Criteria  Map  to  Integrated  Requirements,  the  organization  is  able  to  identify  the 
requirements  in  the  CMM  that  it  has  met,  as  well  as  the  ones  it  has  not  met. 

3.4  Start  with  the  Current  Process.  Most  organizations  have  some  level  of  process 
description  accomplished  at  present.  For  these  organizations  (especially  those  that  have 
an  organization  process  description  as  described  at  Maturity  Level  3  of  the  CMM),  it  may 
be  most  beneficial  to  map  the  process  description  to  the  integrated  set  of  requirements  or 
the  converse.  From  this  mapping,  the  organization  will  see  what  requirements  from 
either  model  are  missing  from  its  process  descriptions  since  the  integrated  set  is 
correlated  to  both  models. 
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4.0  Guide  to  Codes 


4. 1  Capability  Maturity  Model  Codes. 

4.1.1  Key  Process  Areas  (KPAs): 

RM  Requirements  Management 
PP  Software  Project  Planning 

PT  Software  Project  Tracking  &  Oversight 

SM  Software  Subcontract  Management 

QA  Software  Quality  Assurance 

CM  Software  Configuration  Management 

PF  Organization  Process  Focus 

PD  Organization  Process  Definition 

TP  Training  Program 

IM  Integrated  Software  Management 

PE  Software  Product  Engineering 

IC  InterGroup  Coordination 

PR  Peer  Reviews 

QP  Quantitative  Process  Management 

SQ  Software  Quality  Management 

DP  Defect  Prevention 

TC  Technology  Change  Management 

PC  Process  Change  Management 

4.1.2  Other  Common  Features  (OCFs): 

Co  Commitment  to  Perform 

Ab  Ability  to  Perform 

Me  Measurement  and  Analysis 

Ve  Verifying  Implementation 
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4.2  Quality  Air  Force  Criteria  Codes 


1.0  Leadership 

1 . 1  Senior  Executive  Leadership 

1.2  Leadership  System  and  Organization 

1.3  Public  Responsibility  and  Citizenship 
2.0  Information  and  Analysis 

2. 1  Management  of  Information  and  Data 

2.2  Comparisons  and  Benchmarking 

2.3  Analysis  and  Use  of  Organization-Level  Data 
3.0  Strategic  Planning 

3.1  Strategy  Development 

3.2  Strategic  Deployment 

4.0  Human  Resource  Development  and  Management 

4.1  Human  Resource  Planning  and  Evaluation 

4.2  High  Performance  Work  Systems 

4.3  Member  Education,  Training,  and  Development 

4.4  Well  Being  and  Satisfaction 
5.0  Process  Management 

5.1  Design  and  Introduction  of  Products  and  Services 

5.2  Key  Process  Management:  Product  and  Service  Production 

and  Delivery 

5.3  Process  Management:  Support  Services 

5.4  Supplier  Performance  Management 
6.0  Performance  Results 

6.1  Product  and  Service  Quality 

6.2  Operational  Performance  and  Financial  Results 

6.3  Supplier  Performance  Results 
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7.0  Customer  Focus  and  Customer  Satisfaction 
7.1  Customer  Knowledge 
12  Customer  Management 

7.3  Customer  Satisfaction  Determination 

7.4  Customer  Satisfaction  Results 

7.5  Customer  Satisfaction  Comparison 
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Name 

ID 

Purpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Develop  Organizational  Values 

AF-0001 

To  develop  organizational  values  based  on  Air  Force  values,  member  values, 

ethics,  standards  of  conduct,  etc. 

l.l.a 

Senior  Leaders 

AF  Values,  Member  Values,  Customer  Values,  Ethics,  Legalities,  Public 

Concerns 

Organizational  Values 

Name 

Set  Directions 

ID 

AF-0002 

Purpose 

To  set  organizational  directions  based  on  customer  requirements,  internal  and 
external  factors,  while  considering  public  concerns 

Correlates  to 

l.l.a 

Agents 

Senior  Leaders 

Inputs 

Customer  Requirements,  Customer  Expectations,  Organizational  Data  Analysis, 
External  Data  Analysis,  Public  Concerns 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Organizational  Directions 

- - - - - — 1 

Name  Set  Expectations 

ID  AF-0003 


Purpose  To  set  organizational  expectations  based  on  organizational  direction,  internal  and 

external  environments,  and  customer  requirements 
Correlates  to  1.1. a 

Agents  Senior  Leaders 

Inputs  Customer  Requirements,  Organizational  Directions,  Organizational  Data 

Analysis,  External  Data  Analysis 
Outputs  Organizational  Expectations 

Entrance  Criteria 
Exit  Criteria 

Comments  _ 
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Name 

Review  Organizational  Performance 

ID 

AF-0004 

Purpose 

To  find  improvement  opportunities  by  reviewing  and  assessing  organizational 
performance  against  customer  requirements,  external  factors,  and  strategic  plans. 

Correlates  to 

1.2.C 

Agents 

Senior  Leaders 

Inputs 

Customer  Requirements,  Strategic  Plans,  Organizational  Data  Analysis,  External 
Data  Analysis 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Organizational  Performance  Review  Actions,  Review  Information 

Name 

Review  Organizational  Structure 

ID 

AF-0005 

Purpose 

To  review  the  organizational  structure  with  respect  to  customer  requirements  and 
organizational  performance,  for  improvement  opportunities 

Correlates  to 

1.2.a,  1.1. b 

Agents 

Reviewers 

Inputs 

Organizational  Structure,  Key  Performance  Drivers,  Organizational  Performance 
Review  Actions,  Organizational  Data  Analysis 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Organizational  Structure  Review  Actions,  Review  Information 

Name 

Determine  Customer  Data  Requirements 

ID 

AF-0006 

Purpose 

To  determine  customer  data  requirements  such  as  the  types,  formats,  media. 

frequency,  etc. 

Correlates  to 

2.1.a 

Agents 

Workers 

Inputs 

Customer  Requirements,  Customer  Data  Analysis 

Outputs 

Customer  Data  Requirements 

Entrance  Criteria 

Exit  Criteria 

Comments 
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Name 

ID 

Purpose 

Correlates  to 
gents 
Inputs 
Outputs 

ntrance  Criteria 
xit  Criteria 
Comments 


Determine  Benchmarking  Requirements 
AF-0007 

To  determine  benchmarking  needs  based  on  processes,  organizational  goals,  and 

performance  drivers 

2.2.a 

Workers 

Organizational  Goals,  Performance  Objectives,  Organizational  Data  Analysis 
Benchmarking  Requirements 


p— - 

Name 

Set  Benchmarking  Priorities 

io 

AF-0008 

Purpose 

To  determine  benchmarking  priorities  based  on  processes,  organizational  goals, 
performance  drivers,  and  benchmarking  needs 

Correlates  to 

2.2.a 

Agents 

Senior  Leaders,  Workers 

Inputs 

Organizational  Goals,  Performance  Objectives,  Organizational  Data  Analysis, 

Benchmarking  Requirements 

Outputs 

Entrance  Criteria 

Benchmarking  Priorities 

Exit  Criteria 
Comments 

Benchmarking  Priorities  include  all  Benchmarking  Requirements 

Name 

Determine  Benchmarking  Data  Criteria 

ID 

AF-0009 

Purpose 

To  determine  the  criteria  for  selecting  benchmarking  data  based  on  processes, 
organizational  goals,  performance  drivers,  and  benchmarking  needs 

Correlates  to 

2.2.a 

Agents 

Workers 

Inputs 

Performance  Indicators,  Benchmarking  Priorities 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Benchmarking  Data  Selection  Criteria 
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Name 

Aggregate  Data 

ID 

AF-0010 

Purpose 

To  aggregate  data  from  across  the  organization  in  order  to  get  an  organizational 
perspective  of  that  data. 

Correlates  to 

2.3.a 

Agents 

Workers 

Inputs 

Input  Data 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Aggregate  Data 

ame 

ID 

Purpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Name 

ID 

Purpose 
Correlates  to 
Agents 
Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Build  Organizational  Capabilities 
AF-0011 

To  build  organizational  capabilities  based  on  customer  requirements,  external 
environment,  organizational  goals,  and  values 
1.1. a,  4.3.a 

Senior  Leaders,  Workers 

Organizational  Goals,  Organizational  Information,  Current  Capabilities,  Customer 

Requirements 

Organizational  Capabilities 


This  requirement  involves  a  lot  of  other  requirements  including  training,  process 
improvements,  technology  management,  etc. 

Linkage  between  Organizational  Capabilities  &  Customer  Requirements  is  key. 


Improve  Leadership  System 
AF-0012 

To  improve  the  processes  which  make  up  the  leadership  system  as  a  whole, 
l.l.b 

Senior  Leaders,  Workers 

Leadership  System,  Process  Improvement  Actions,  Improvement  Priorities, 
System  Data  Analysis 
Leadership  System 
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Name 

ID 

Purpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Improve  Organization  Structure 

AF-0013 

To  improve  how  the  organization  is  structured,  based  on  the  input  actions. 

1.1. b,  1.2.a 

Workers 

Organizational  Structures,  Structure  Review  Actions 

Organizational  Structures 

Name 

Set  Objectives 

ID 

AF-0014 

Purpose 

To  set  objective  based  on  higher  level  goals 

Correlates  to 

3.1.b,PP.Ac7 

Agents 

Workers 

Inputs 

Goals 

Outputs 

Entrance  Criteria 

Objectives 

Exit  Criteria 
Comments 

All  Goals  Supported  by  Objectives 

Name 

Determine  Key  Performance  Drivers 

ID 

AF-0015 

Purpose 

To  determine  key  performance  drivers  based  on  customer  requirements, 
organizational  plans,  and  analysis  of  strategic  data. 

Correlates  to 

3.1.b 

Agents 

Workers 

Inputs 

Strategic  Plans,  Customer  Requirements,  Organizational  Data  Analysis,  External 
Data  Analysis 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Key  Performance  Drivers 

Key  Performance  Drivers  are  a  set  of  requirements  that  emphasize  what  is  most 

Key  Performance  Drivers  are  a  set  of  requirements  that  emphasize  what  is  most 
important  to  the  organization _ 


Name 

ID 

Purpose 
Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


ame 

ID 

Purpose 

Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Project  Key  Indicator  Data 
AF-0016 

To  project  key  data  2-5  years  in  the  future  based  on  current  and  past  data. 

3.2.b 

Workers 

Indicators,  Current  Data,  Current  Data  Analysis,  Current  Data  Context 
Projected  Data 

Current  Data  associates  to  Indicators 

Indicators  may  identify  any  type  of  data  the  organization  deems  important  to 
redicting  future  performance.  


Name 

Determine  Benefits 

ID 

AF-0017 

Purpose 

To  determine  the  benefits  due  to  process  improvements  by  looking  at  projected 

data  analysis. 

Correlates  to 

3.2.b 

Agents 

Workers 

Inputs 

Projected  Data  Analysis 

Outputs 

Improvement  Benefits 

Entrance  Criteria 

Exit  Criteria 

Comments 

Evaluate  Training 
AF-0018 

To  evaluate  training  and  education  and  the  processes  that  determine  how  they  are 
delivered. 

4.3.a,  4.3.b,  TP.Ve3 
Evaluators 

Training  Courses,  Training  Processes,  Training  Needs,  Training  Data  Analysis 
Training  Actions 


Training  includes  education  and  OJT. 

The  evaluation  addresses  Training  Processes  including  reinforcement  of  training, 
how  training  is  identified,  or  any  other  processes  associated  with  training.  One 
key  aspect  is  the  linkage  between  training  and  organizational  capabilities. _ 
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ame 

ID 

Purpose 

Correlates  to 

Agents 

Inputs 


Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Set  Goals 

AF-0019  ! 

To  set  goals  at  the  organizational  level  based  on  direction,  customer  requirements, 
values,  and  community  concerns. 
l.l.a,PC.Ac2,  PC.Ac4 
Senior  Leaders,  Planners 

Organizational  Directions,  Customer  Requirements,  Customer  Expectations, 
Organizational  Expectations,  Organizational  Values,  Organizational  Capabilities, 
Supplier  Capabilities,  Financial  Risks,  Mission  Risks,  Technological  Risks 
Organizational  Data  Analysis,  External  Data  Analysis 
Organizational  Goals 


Other  Planners  may  be  involved,  but  at  the  organizational  level.  Senior  Leaders 
must  be  deeply  involved  and  be  the  driver  of  this  process. 

Not  all  these  Inputs  may  be  applicable  or  have  much  impact  on  a  particular 
organization,  but  should  be  considered,  as  well  as  any  other  issues  or  situations 


Name 

Assess  Community  Involvement 

ID 

AF-0020 

Purpose 

To  determine  the  quantity  and  quality  of  community  involvement  by  the 

organization. 

Correlates  to 

1.3.b 

Agents 

Senior  Leaders,  Workers 

Inputs 

Community  Involvement  Plans,  Community  Activities 

Outputs 

Community  Involvement  Data,  Community  Involvement  Information 

Entrance  Criteria 

Exit  Criteria 

Comments 

Senior  Leaders  may  not  do  the  assessment,  but  the  information  and  data  is  theirs. 

Name 

Improve  Community  Involvement 

ID 

AF-0021 

Purpose 

To  improve  the  quantity  and/or  quality  of  community  involvement  activities  by 
the  organization. 

Correlates  to 

1.3.b 

Agents 

Senior  Leaders,  Workers 

Inputs 

Citizenship  Goals,  Community  Actions,  Community  Activities,  Community  Data 
Analysis 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Community  Activities 
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Name 

Improve  Work  Organization 

ID 

AF-0025 

Purpose 

To  improve  the  formal  and  informal  work  structures  throughout  the  organization. 

Correlates  to 

4.2.a 

Agents 

Workers 

Inputs 

Improvement  Priorities,  Work  Organizations,  Work  Organization  Actions 

Outputs 

Entrance  Criteria 
Exit  Criteria 

Work  Organizations 

Comments 

Job  Structures  are  the  way  jobs  (or  processes)  are  laid  out,  for  example  the  layout 
of  desktop  computers.  Work  Organizations  refer  to  the  way  people  are  organized 
and  relate  to  each  other. 

Name 

Improve  Job  Design 

ID 

AF-0026 

Purpose 

To  improve  the  formal  and  informal  job  structures  throughout  the  organization. 

Correlates  to 

4.2.a 

Agents 

Workers 

Inputs 

Improvement  Priorities,  Job  Designs,  Job  Design  Actions 

Outputs 

Entrance  Criteria 
Exit  Criteria 

Job  Designs 

Comments 

Job  Structures  are  the  way  jobs  (or  processes)  are  laid  out,  for  example  the  layout 
of  desktop  computers.  Work  Organizations  refer  to  the  way  people  are  organized 
and  relate  to  each  other. 

Name 

ID 

Purpose 
Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Recognize  Member 
AF-0027 

To  recognize  members  for  demonstrating  the  values  of  the  organization, 
l.l.a,  4.2.b 

Senior  Leaders,  Workers 

Members,  Organizational  Values,  Recognition  Criteria 
Recognition 


Organizational  Values  should  relate  performance  ideals  in  addition  to  tenets  such 
as  honesty,  integrity,  duty,  honor,  country,  etc.  This  is  one  way  to  reinforce 
Organizational  Values.  Recognition  Criteria  specify  the  requirements. 

Also  Relates  to  informal  recognition  for  which  criteria  is  inappropriate. 

Although  any  Worker  may  recognize  other  Members,  it  is  incumbent  on  Senior 
Leaders  to  be  an  integral  part  of  recognition  activities. _ _ 
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Name 

ID 

Purpose 

Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Compensate  Member 
AF-0028 

To  compensate  members  for  performing  their  roles,  including  special 
compensations  as  rewards. 

4.2.b 

Workers 

Members,  Member  Compensation,  Special  Compensation 
Compensated  Members 


Compensation  may  include  days  off,  free  time,  or  special  events  in  the  context  of 
military  organizations.  _ 


Name 

Evaluate  Member 

ID 

AF-0029 

Purpose 

To  evaluate  members  based  on  the  criteria  for  their  jobs  and  how  well  the 
members  perform  them. 

Correlates  to 

4.2.b 

Agents 

Evaluators,  Members 

Inputs 

Members,  Member  Data  Analysis,  Job  Criteria 

Outputs 

Entrance  Criteria 

Member  Actions 

Exit  Criteria 

Job  Criteria  NOT  Met  Implies  Member  Actions  Identified 

Comments 

Members  are  included  as  agents  to  this  process,  as  well  as  an  input.  Members 
should  play  an  active  role  in  their  evaluations,  e.g.  Air  Force  mandated  feedback 
sessions  .  This  should  be  considered  when  choosing  processes  to  meet  this 
requirement. 

Name 

Improve  Training 

ID 

AF-0030 

Purpose 

To  improve  training  for  organization  members  and  how  it  is  delivered. 

Correlates  to 

4.3.b 

Agents 

Inputs 

Workers,  Training  Group 

Training  Courses,  Training  Processes,  Training  Actions,  Improvement  Priorities, 

Training  Data  Analysis 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Training  Courses 
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1 - 

Name 

Assess  Member  Services 

ID 

AF-0035 

Purpose 

To  determine  the  adequacy  of  services  provided  by  the  organization  to  its 
members. 

Correlates  to 

4.4.b 

Agents 

Workers 

Inputs 

Member  Services,  Human  Resource  Information 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Member  Service  Data,  Member  Service  Information 

Name 

Assess  Member  Facilities 

ID 

AF-0036 

Purpose 

To  determine  the  adequacy  of  facilities  provided  by  the  organization  to  its 

members. 

Correlates  to 

4.4.b 

Agents 

Workers 

Inputs 

Member  Facilities,  Human  Resource  Information 

Outputs 

Member  Facility  Data,  Member  Facility  Information 

Entrance  Criteria 

Exit  Criteria 

Comments 

Name 

Assess  Member  Activities 

ID 

AF-0037 

Purpose 

To  determine  the  adequacy  of  activities  provided  by  the  organization  for  its 
members. 

Correlates  to 

4.4.b 

Agents 

Workers 

Inputs 

Member  Activities,  Human  Resource  Information 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Member  Activity  Data,  Member  Activity  Information 

Name 

Design  Process 

ID 

AF-0038 

Purpose 

To  support  process  improvement  by  improving  process  designs  based  on  required 
process  actions. 

Correlates  to 

5.1.a,PD.Acl,PD.Ac2 

Agents 

Workers 

Inputs 

Processes,  Process  Actions,  Improvement  Plans,  Process  Requirements 

Outputs 

Entrance  Criteria 

Processes 

Exit  Criteria 
Comments 

Processes  Meet  Process  Requirements 
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Name 

Design  Service 

ID 

AF-0039 

Purpose 

To  support  process  improvement  by  improving  service  designs. 

Correlates  to 

S.l.a 

Agents 

Workers 

Inputs 

Services,  Service  Actions,  Improvement  Plans,  Service  Requirements 

Outputs 

Entrance  Criteria 

Services 

Exit  Criteria 
Comments 

Services  Meet  Service  Requirements 

Name 

ID 

Purpose 
Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
xit  Criteria 
Comments 


Name 

ID 

Purpose 

Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 


Comments 


Maintain  Improvement  Program 
AF-0040 

To  ensure  members  are  empowered  to  make  positive  change  in  the  organization. 

PF.Co2,  PF.Co3,  PC.Acl 

Senior  Leaders,  Workers 

Organization 

Improvement  Program 

Members  Empowered 

The  program  consists  of  all  the  improvement  processes,  plans,  and  activities. 
Senior  Leaders  are  primarily  responsible  for  establishing,  sponsoring,  and 
maintaining  such  a  program.  Workers  from  the  organization  participate  on  an  as 
needed  basis,  i.e.,  to  serve  on  improvement  teams  or  process  focal  group. _ 


Test  Product 
AF-0041 

To  test  the  product  design  to  ensure  it  meets  design  requirements  and  performance 
objectives  spelled  out  in  the  implementation  plan. 

5.1.b 

Workers 

Products,  Implementation  Plans,  Design  Requirements 
Design  Actions,  Design  Data 

(Design  Requirements  NOT  Met)  OR  (Performance  Objectives  NOT  Achieved) 
Implies  Design  Actions  Identified 
Design  Data  Recorded 

Performance  Objectives  are  in  the  Implementation  Plans,  and  based  on  design 
requirements.  Key  Performance  Objectives,  and  Key  Performance  Drivers. _ 
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Name 

ID 

Purpose 


Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 


Comments 


Test  Service 
AF-0042 

To  test  the  service  design  to  ensure  it  meets  design  requirements,  performance 
objectives  spelled  out  in  the  implementation  plan,  and  determine  if  there  are  ways 
to  improve  the  design  before  fully  implementing  it. 

S.l.b 

Workers 

Services,  Implementation  Plans,  Service  Design  Requirements 
Service  Design  Actions,  Service  Design  Data 

Service  Meets  Service  Design  Requirements  AND  Service  Achieves  Service 
Performance  Objectives)  OR  (Service  Design  Actions  Identified) 

Service  Data  Recorded 

Service  Performance  Objectives  should  be  documented  as  part  of  the 
Implementation  Plans,  and  are  based  on  the  design  requirements.  Key 
Performance  Objectives,  and  Key  Performance  Drivers. _ _ 
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Name 

ID 

Purpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Name 

ID 

Purpose 
Correlates  to 
Agents 
Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Build  Supplier  Relationship 
AF-0045 

To  build  a  strong  relationship  with  suppliers  in  order  to  facilitate  communication 
and  cooperation  between  the  supplier  and  the  organization. 

5.4.b 

Workers 

Suppliers,  Supplier  Relationship,  Supplier  Processes,  Supplier  Requirements, 
Supplier  Data  Analysis 
Supplier  Relationship 


Supplier  Relationship  implies  the  infrastructure,  i.e.  the  lines  of  communication, 
formal  and  informal  systems,  that  are  the  architecture  for  using  processes  Supplier 
Requirements  are  used  for  context  in  understanding  the  relationship. 

In  a  newly  formed  relationship,  or  a  newly  formed  focus,  the  Supplier 
Relationship  information.  Supplier  Processes  and  Supplier  Data  Analysis  may  be 
not  be  available. _ 


Determine  Customer  Requirements 
AF-0046 

To  determine  customer  requirements  for  the  organization. 

7.1.a 

Workers,  Customers 

Customer  Expectations,  Customer  Goals,  Customer  Information,  Customer  Data 
Analysis 

Customer  Requirements 
Customer  Requirements  Documented 

This  requirement  differs  from  AF-0166.  It  is  focused  on  the  problem  domain,  i.e., 
determining  customer  needs.  AF-0166  addresses  the  solution  space,  i.e.  what 
system  is  needed. 

This  requirement  would  normally  be  fulfilled  by  requirements  elicitation 
processes,  as  well  as  informal  discussions  and  interaction  with  the  customer. 
Customers  are  considered  Agents  of  the  this  process  not  as  Inputs.  The  subtle 
difference  is  as  Agents  they  are  active  participants  that  help  guide  the  process;  as 
Inputs  are  being  acted  upon  by  Agents  and  may  not  be  seen  as  part  of  the  team. 
The  difference  is  important  in  selecting  a  process  to  fulfill  the  requirement. 
Customer  Information  includes  Values  and  Expectations,  as  well  as  any  other 
information  the  organization  may  have  on  the  customer. _ _ _ 
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Name  Determine  Customer  Expectations 

ID  AF-0047 

Purpose  To  determine  customer  expectations  for  the  organization. 

Correlates  to  7.1. a 

Agents  Workers,  Customers 

Inputs  Customer  Goals,  Customer  Information,  Customer  Data  Analysis 

Outputs  Customer  Expectations 

Entrance  Criteria 
Exit  Criteria 

Comments  This  requirement  concerns  expectations  the  customer  has  for  the  organization  as  a 

whole,  and  also  to  specific  expectations  related  to  the  work  to  be  done. 

Customers  are  considered  Agents  of  this  process  not  Inputs.  The  subtle  difference 
is  that  Agents  are  active  participants  that  help  guide  the  process;  Inputs  are  being 
acted  upon  by  Agents  and  may  not  be  seen  as  part  of  the  team.  The  difference  is 
important  in  selecting  a  process  to  fulfill  the  requirement. 

Customer  Information  includes  Values,  as  well  as  any  other  information  the 
_  organization  may  have  on  the  customer. _ 

Name  Determine  Future  Customer  Requirements 

ID  AF-0048 

Purpose  To  take  a  long-term  approach  to  meeting  customer  needs  by  determining  possible 

future  customer  requirements  based  on  current  requirements,  expectations,  and 
customer  goals  for  the  future. 

Correlates  to  7.1.b 

Agents  Workers,  Customers 

Inputs  Customer  Goals,  Customer  Information,  Customer  Requirements,  Projected 

Customer  Data  Analysis 

Outputs  Future  Customer  Requirements 

Entrance  Criteria 
Exit  Criteria 

Comments  Customers  are  considered  Agents  of  this  process  not  Inputs.  The  subtle  difference 

is  that  Agents  are  active  participants  that  help  guide  the  process;  Inputs  are  being 
acted  upon  by  Agents  and  may  not  be  seen  as  part  of  the  team.  The  difference  is 
important  in  selecting  a  process  to  fulfill  the  requirement. 

Customer  Information  includes  Values  and  Expectations,  as  well  as  any  other 
_  information  the  organization  may  have  on  the  customer. _ _ 
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Name  Follows  Procedure 

ID  AF-0058 

Purpose  To  ensure  institutionalization  of  standard  processes,  practices,  and  activities  to 

provide  the  basis  for  quantitative  management  of  processes.  A  second  purpose  is 
to  facilitate  alignment  of  activities  and  processes  performed  to  organizational 


policies. 

Correlates  to 

Co 

Agents 

None 

Inputs 

Process 

Outputs 

Boolean 

Entrance  Criteria 
Exit  Criteria 

Comments  This  is  not  so  much  a  requirement  for  a  process  as  it  is  a  pre-condition  for  other 

required  processes.  It  is  stated  in  CMM,  but  is  embodied  in  the  QAF  in 
requirements  to  design,  plan,  deploy,  measure,  and  manage  processes. 

It  may  be  beneficial  to  initiate  explicit  review  cycles  (similar  to  those  based  Align 
Internal  Plans)  to  ensure  procedure  are  in  place  and  reflect  the  organization’s 
policies.  The  specifically  requires  reviews  used  to  ensure  procedures  are 
performed  as  documented.  _ 


Name 

Determine  Status 

ID 

AF-0059 

Purpose 

To  determine  the  status  of  the  activity  based  on  the  data  collected. 

Correlates  to 

Me 

Agents 

Workers 

Inputs 

Activities,  Data 

Outputs 

Project  Status 

Entrance  Criteria 

Exit  Criteria 

Comments 

Name 

Allocate  Requirements 

ID 

AF-0060 

Purpose 

To  allocate  system  requirements  to  software,  hardware,  or  other  system 
components. 

Correlates  to 

RM.Abl,  RM.Ab2 

Agents 

Systems  Engineering  Group,  SW  Engineering  Group,  H  W  Engineering  Group 

Inputs 

System  Requirements 

Outputs 

Entrance  Criteria 

Allocated  Software  Requirements,  Hardware  Requirements,  Other  Requirements 

Exit  Criteria 

All  Requirements  Documented 

Comments 

This  may  be  a  responsibility  of  the  Systems  Engineering  Group,  but  should  have 
input  and  involvement  from  the  SW  Engineering  Group  and  H  W  Engineering 
Group. 
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Name 

Assess  Requirements  Change 

ID 

AF-0061 

Purpose 

To  assess  the  impact  of  changes  to  the  allocated  requirements. 

Correlates  to 

RM.Ac3 

Agents 

SW  Engineering  Group 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Allocated  Requirements,  Change  Requirements,  Project  Data  Analysis 

Impact  Data,  Impact  Information 

Name 

ID 

Purpose 


Correlates  to 

kgents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Name 

ID 

Purpose 

Correlates  to 
gents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Evaluate  Improvement  Linkage 
AF-0062 

To  analyze  the  connection  between  the  customer,  processes,  and  improvements. 
Answers  the  question,  “Are  improvements  directly  related  to  improving  mission 
effectiveness,  customer  satisfaction,  performance,  etc.?” 

2.3.b 

Workers 

Customer  Requirements,  Processes,  Improvement  Plans,  Organizational  Data 
Analysis, 

Improvement  Actions,  Improvement  Information 


Related  to  assessing  processes,  but  also  to  aligning  plans.  The  point  of  this 
requirement  is  to  ensure  improvements  directly  support  the  business  of  the 
organization. 

Organizational  Data  Analysis  may  be  practically  any  analysis  that  contributes  to 
understanding  these  linkages.  Specifically,  it  should  include  analysis  of  Customer 
Data,  Mission  Effectiveness  Data,  Performance  Data,  Quality  Data,  and  Financial 
Data. _  _ 


Develop  Project  Proposal 
AF-0063 

To  develop  a  project  proposal  which  encompasses  all  areas  including  hardware, 
software,  and  other  components  of  the  system. 

PP.Acl 

Proposal  Team 

SOW,  Customer  Information 

Proposal 


Customer  Information  includes  Values,  Expectations,  Goals,  etc. 
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Name 

ID 

Purpose 
Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Perform  Supplier  Acceptance  Tests 
AF-0064 

To  test  the  supplier’s  product  to  ensure  it  meets  acceptance  criteria. 

5.4.a,SM.Acl2 

Organization  Testers 

Supplier  Products,  Acceptance  Criteria,  Testing  Plans,  Test  Procedures 
Corrective  Actions,  Accepted  Products 
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Name 

ID 

Purpose 
Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Identify  Software  Configuration  Items 
AF-0067 

To  identify  the  software  configuration  items  for  the  project. 

CM.Ac2,  CM.Ac4 
SW  Engineering  Group,  CM  Group 

Software  Development  Plan,  Software  Requirements,  Selection  Criteria 
SCIs 
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Name  Determine  Indicators 

ID  AF-0071 

Purpose  To  determine  the  appropriate  indicators  based  on  objectives,  priorities  and  criteria, 

Correlates  to  2. 1  .a,  2.2. a,  5.4.a,  7. 1  .a,  QP.Ac3,  QP.Ac4 

Agents  Workers 

Inputs  Performance  Drivers,  Performance  Objectives,  Priorities,  Criteria 

Outputs  Indicators 

Entrance  Criteria 
Exit  Criteria 

Comments  _ 


Name 

Measure  Process 

ID 

AF-0072 

Purpose 

To  collect  process  data  based  on  the  input  indicators 

Correlates  to 

l.l.a,  5.2.a,  5.3.b,  5.4.a,  6.2.a,  6.3.a,  QP.Ac2,  QP.Ac4,  PC.AcS,  PC.Mel,  Me 

Agents 

Workers 

Inputs 

Processes,  Process  Indicator,  Plans 

Outputs 

Entrance  Criteria 

Process  Data 

Exit  Criteria 

Process  Data  Documented  in  Process  Database 

Comments 

At  ML2,  Process  Database  may  not  be  formalized. 

Vame 

Analyze  Data 

ID 

AF-0073 

Purpose 

To  analyze  data  based  on  the  input  criteria  and  the  context  of  where  the  data 
comes  from. 

Correlates  to 

l.l.a,  2.2.a,  2.3.a,  3.2.b,  5.2.a,  5.3.b,  5.4.a,  6.1.a,  6.2.a,  6.3.a,  7.2.b,  7.2.c,  7.3.a, 
7.3.b,  7.4.a,  7.4.b,  7.5.a,  7.5.b,  PT.Acll,  PF.Ac4,  IM.Ac4,  IM.AcS,  PE.Ac9, 
PE.Mel,  QP.Ac2,  QP.Ac4,  SQ.Ac2,  SQ.Ac4,  DP.Ac5,  PC.AcS,  PC.Mel,  Me 

Agents 

Workers 

Inputs 

Input  Data,  Measured  Process,  Measured  Product,  Measurement  Criteria, 
Performance  Objectives,  Contextual  Information 

Outputs 

Entrance  Criteria 
Exit  Criteria 

Data  Analysis 

Comments 

Data  is  analyzed  based  on  its  numerical  characteristics,  as  well  as  the  context  from 
which  it  is  gathered.  All  collected  data  should  be  analyzed. 

Analysis  of  data  includes  comparison  with  other  data,  i.e.  comparisons  ol 
benchmarking  data,  comparative  performance  data,  customer  satisfaction  data 
called  for  by  the  QAF  criteria  are  all  covered  by  this  requirement 

Methods,  tools,  and  criteria  for  analyzing  data  is  coordinated  at  the  organization 
level  for  ML3  and  higher. 
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Name 

Gather  External  Information 

ID 

AF-0084 

Purpose 

To  gather  data  and  information  from  external  sources  to  use  in  benchmarking  or 

comparisons. 

Correlates  to 

2.2.a 

Agents 

Workers 

Inputs 

Priorities,  Indicators,  Sources 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Information,  Data 

Name 

D 

Purpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 

Comments 


Name 

ID 

Purpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Determine  Partnering  Activities 
AF-0085 

To  determine  what  activities  can  not  or  will  not  be  performed  by  the  organization, 
but  will  be  accomplished  by  seeking  a  partner  or  supplier  to  perform  the  activity. 
5.4.b,SM.Acl 
Senior  Leaders,  Workers 

Goals,  Current  Capabilities,  Needed  Capabilities,  Organizational  Data  Analysis, 
External  Data  Analysis 
Partnering  Actions 

Needed  Capabilities  NOT  Obtainable  by  the  Organization 
Implies  Partnering  Actions  Identified 

This  process  may  be  used  at  the  strategic  level,  where  Goals  are  organizational,  or 
at  the  project  level,  where  Goals  are  the  goals  of  the  project. 

Partnering  Actions  are  those  needed  to  acquired  the  Needed  Capabilities. _ 


Align  Plans 
AF-0086 

To  review  organizational  plans  to  ensure  alignment  from  organizational  directions 
down  to  implementation  of  processes  to  meet  customer  requirements. 

3.2.a,4.1.b 

Senior  Leaders,  Workers 

Organizational  Plans,  Customer  Requirements,  Organizational  Directions, 
Organizational  Goals,  Key  Performance  Drivers,  Key  Performance  Objectives 
Alignment  Actions 


This  is  a  requirement  for  a  review  cycle  in  addition  to  a  day-to-day  focus. 

This  requirement  addresses  alignment  of  Supplier  plans  also,  QAF  3.2.a. 
Organizational  Plans  include  any  plan  to  include  Training  Plans,  Improvement 
Plans.  Project  Plans,  Quality  Assurance  Plans,  Measurement  Plans,  etc. _ 
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Name  Reinforce  Training 

ID  AF-0087 

Purpose  To  ensure  training  and  education  members  receive  are  understood  and  practiced. 

Correlates  to  4.3.b 

Agents  Workers 

Inputs  Members,  Training  Concerns 

Outputs  Capabilities 

Entrance  Criteria 

Exit  Criteria 

Comments  The  are  a  variety  of  ways  to  accomplish  this,  including  written  tests,  performance 

tests,  refresher  sessions,  etc. _ _ 


A-35 
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Name 

ID 

rpose 


Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


ame 

ID 

Purpose 
Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
xit  Criteria 
Comments 


Name 

ID 

Purpose 

Correlates  to 
gents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Communicate  Information 
AF-0097 

For  one  group  to  communicate  information  about  their  activities,  products,  or 
performance  to  other  groups,  or  to  provide  feedback  on  another  groups  activities, 
products,  or  performance. 

5.4.a,  7.2. a,  QA.Ac2,  QA.Ac6,  QA.AcS,  CM.Ac2,  CM.Ac9,  PF.Ac7,  QP.Ac2, 

QP.Ac6,  DP.AcS,  TC.Ac3,  PC.Ac4,  PC. Ac  10 

Providers 

Receivers,  Information,  Plans 
Information 

Receivers  Informed 

This  requires  a  process  for  disseminating  information  about  any  topic. 
Information  may  include  reports  on  activities,  performance,  products,  etc. 

Most  likely  there  would  be  several  varieties  of  this  process.  _ 


Gather  Internal  Data 
AF-0098 

To  gather  data  from  across  the  organization. 

2.3.a,  6.1. a,  6.2.a,  PP.AclS,  PD.AcS 

Workers 

Sources,  Data 

Internal  Data 


This  is  a  requirement  to  report  data  up  the  chain  to  organizational  leadership 


Determine  Customer  Groups 
AF-0099 

To  determine  groups  or  segments  of  customers  with  the  goal  of  providing 
products,  services,  or  information  to  better  serve  a  particular  group  or  segment. 
7.1.a,7.3.a 
Workers,  Customers 

Customer  Requirement  Sets,  Customer  Data  Analysis  Sets 
Customer  Groups 


Name 

Select  Group 

ID 

AF-0100 

Purpose 

To  select  a  group  as  a  supplier  or  customer  for  a  specific  purpose. 

Correlates  to 

7.1.a,SM.Ac2 

Agents 

Inputs 

Workers 

Groups,  Selection  Criteria 

Outputs 

Entrance  Criteria 

Selected  Groups 

Exit  Criteria 
Comments 
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Name 

ID 

Purpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Gather  Customer  Feedback  Data 

AF-0105 

To  gather  and  record  feedback  data  from  the  customer  concerning  any  of  the 
organization’s  services,  products,  processes,  standards,  etc. 

7.2.a 

Workers 

Customers,  Indicators 

Feedback  Data,  Customer  Information 

Name 

Record  Customer  Complaint 

ID 

AF-0106 

Purpose 

To  record  customer  complaints  as  accurately  as  possible. 

Correlates  to 

7.2.b 

Agents 

Workers,  Customers 

Inputs 

Customers,  Customer  Requirements,  Information,  Data  Analysis 

Outputs 

Complaints,  Complaint  Data 

Entrance  Criteria 

Exit  Criteria 

Comments 

Name 

Evaluate  Customer  Complaint 

ID 

AF-0107 

Purpose 

To  determine  possible  course  of  action  to  resolve  customer  complaints. 

Correlates  to 

7.2.b 

Agents 

Workers,  Customers 

Inputs 

Complaints,  Customer  Requirements,  Standards,  Data  Analysis,  Information 

Outputs 

Complaint  Actions 

Entrance  Criteria 

Exit  Criteria 

Comments 

Name 

ID 

Purpose 
Correlates  to 
gents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 

Comments 


Review  Product 
AF-0108 

To  review  work  products  and  identify  actions  necessary  to  remedy  problems. 
5.1.b,  SM.Ac4,  QA.Ac2,  QA.Ac5,  QA.Ac7,  IC.Ac5,  PR.Ac2,  PR.Ac3 
Auditors 

Work  Products,  Work  Product  Criteria,  Plan 
Deviations,  Report 

Work  Product  Criteria  NOT  Met 

Implies  Deviations  Identified  AND  Documented 
Deviations  are  of  type  Action. 

Reviews  can  be  done  on  an  event-driven  basis  (for  which  Plan  would  be  empty), 
but  some  should  be  planned. 

The  process  may  be  used  in  a  variety  of  manners,  e.g.,  to  review  subcontractors 
SDP,  a  supplier  (internal  or  external)  delivery,  or  a  co-worker’s  efforts. _ 
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Name 

ID 

Purpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 

Comments 

Develop  Software  Requirements 

AF-0112 

To  develop  software  requirements  based  on  the  system  requirements  allocated  to 
software. 

RM.Ac2 

SW  Engineering  Group 

Allocated  Requirements 

Software  Requirements 

Allocated  Requirements  Documented  AND  Managed  &  Controlled 

Software  Requirements  Documented  AND  Managed  &  Controlled  AND 

Traceable 

Name 

Change  Supplier  Commitment 

ID 

AF-0113 

Purpose 

To  revise  the  commitment  with  the  supplier. 

Correlates  to 

5.4.b,  PT.Ac4,  SM.Ac6 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 


Comments 


Name 

ID 

Purpose 
Correlates  to 


Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Senior  Leaders,  Representatives,  Supplier  Representatives 
Supplier  Commitment,  Supplier  Requirements,  Suggested  Changes 
New  Supplier  Commitment 
Supplier  Requirements  Documented 
New  Supplier  Commitments  Documented 

New  Supplier  Commitments  (Reviewed  AND  Approved)  by  Senior  Leaders 
New  Supplier  Commitments  (Communicated  OR  Agreed  To) 

If  Supplier  is  internal.  Senior  Leaders  may  not  be  involved. _ 


Project  Planning 
AF-0114 

To  perform  planning  for  the  entire  project,  to  include  action  planning,  defect 
prevention,  quantitative  process  management,  etc. 

5.1. a,  5.2.a,  5.3.b,  PP.Ac2,  PP.Ac3,  PP.AcS,  PP.Ac6,  PP.Ac7,  PP.Acl4,  PT.Acl, 
PT.Ac2,  QA.Acl,  QA.Ac3,  CM.Acl,  TP.Acl,  IM.Ac3,  IM.Ac4,  IM.Ac5,  lC.Ac3, 
IC.Ac4,  QP.Acl,  SQ.Acl,  DP.Acl 
Project  Managers,  Affected  Groups 

Goals,  Objectives,  SOW,  System  Requirements,  PDSP,  Standards,  Commitments 
Project  Plans 

SOW  (Documented  AND  Approved)  AND  Software  LifeCycle  Identified 
Project  Plans  (Documented  AND  Reviewed  AND  Approved) 

This  is  a  generic  planning  process  that  encompasses  all  the  planning  for  a  project. 
Even  though  there  are  a  variety  of  plans  to  develop,  the  process  is  essentially  the 
same  for  each  one.  Also  includes  revising  the  plan,  i.e.,  replanning. 

Not  all  output  plans  are  necessarily  formal  plans. 

For  software  project  planning.  Affected  Groups  must  include  QA  Group. 

At  ML2,  PDSP  may  not  be  formalized. 
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Name  Make  Commitment 

ID  AF-0115 

Purpose  To  make  a  commitment  with  a  supplier. 

Correlates  to  RM.Acl,  RM.Ac3,  PP.Ac4,  PT.Ac3,  SM.Ac3 

Agents  Senior  Leaders,  SW  Engineering  Group,  Suppliers 

Inputs  Supplier  Requirements,  Project  Requirements 

Outputs  New  Supplier  Commitments 

Entrance  Criteria  Supplier  Requirements  Documented 

Exit  Criteria  Supplier  Commitments  (Reviewed  AND  Approved)  by  Senior  Leaders 

Supplier  Commitments  (Documented  AND  Agreed  To) 

Comments  Suppliers  may  be  Other  Affected  Groups  in  the  organization. 

Project  Requirements  may  be  needed  as  the  basis  for  negotiation,  as  Supplier 
Requirements  are  what  the  are  proposed  by  the  SW  Engineering  Group. 

If  Supplier  is  internal.  Senior  Leaders  may  not  be  involved. 

For  external  commitments  with  other  groups,  AF-01 1 1  is  for  internal. _ 


Name 

Take  Corrective  Actions 

ID 

AF-01 16 

Purpose 

To  take  corrective  actions  based  on  problems  in  the  project. 

Correlates  to 

5.2.a,  5.3.b,  PT.Ac5,  PT.Ac6,  PT.AcV,  PT.Ac8,  PT.Ac9,  PT.AclO,  Ve 

Agents 

Project  Manager,  Project  Team,  Affected  Groups 

Inputs 

Corrective  Actions,  Priorities,  Plan 

Outputs 

Actions 

Entrance  Criteria 

Corrective  Actions  Documented  AND  Approved 

Exit  Criteria 

Corrective  Actions  (Performed  AND  Closed) 

Comments 

Although  in  the  CMM  vernacular  taking  corrective  actions  implies  reaction  at 
ML2,  as  opposed  to  “pro”-action  at  (ML3.  However,  corrective  action  as  stated 
here  is  more  general.  It  applies  to  any  actions  taken,  including  proactive  steps. 
This  requirement  is  applicable  to  actions  taken  as  a  result  of  an  evaluation,  audit, 
or  review.  Therefore,  Ve  is  included  in  Correlates  to. 

Name 

Track  Technical  Activities 

ID 

AF-01 17 

Purpose 

To  track  the  technical  activities  of  the  software  development  effort  and  identify 
corrective  actions  if  there  are  problems. 

Correlates  to 

PT.Ac9,  IC.Ac2 

Agents 

SW  Engineering  Group,  Affected  Groups 

Inputs 

Software  Development  Plan,  Technical  Activities 

Outputs 

Entrance  Criteria 

Corrective  Actions,  Technical  Activities  Status 

Exit  Criteria 

Comments 

Software  Development  Plan  NOT  Followed 

Implies  Corrective  Actions  Identified 
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A-44 


A-45 


A-46 


Name 

ID 

urpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 


Comments 


Develop  PDSP 
AF-0130 

To  develop  the  project’s  defined  software  process  based  on  the  organization’s 
standard  software  process  and  tailoring  guidelines. 

QA.Ac3,  PF.Ac3,  IM.Acl,  PE.Acl 
Developers,  Senior  Leaders,  SEPG,  QA  Group 

Software  LifeCycle,  OSSP,  Tailoring  Guidelines,  Software  Engineering  Tasks, 
Software  Methods,  Software  Tools,  Selection  Criteria 
PDSP,  Process  Waivers 

Development  Activities  Coordinated  at  Organization  Level 
PDSP  Reviewed  by  (SEPG  AND  QA  Group)  AND  Approved  by  Senior  Leaders 
PDSP  (Reviewed  AND  Approved)  by  Senior  Leaders 
Managed  &  Controlled 

IM  Activity  1  relates  to  developing  the  PDSP  from  the  OSSP. 

PE  Activity  1  requires  the  input  and  consideration  of  software  engineering 
activities,  methods,  and  tools,  as  well  as  the  criteria  for  choosing  them.  The  idea 
is  to  integrate  these  into  the  PDSP.  _ 


A-47 


A-48 


A-49 
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Name 

ID 

Purpose 

Correlates  to 
gents 
nputs 

Outputs 
ntrance  Criteria 
xit  Criteria 

Comments 


rpose 

Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


rpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 

Comments 


Manage  Effort 
AF-0142 

To  manage  the  effort  of  software  work  products  and  identify  corrective  actions  if 
the  actual  effort  data  exceeds  thresholds. 

PT.Ac6,  IM.Ac? 

SW  Engineering  Group 

Software  Development  Plan,  Effort  Estimates,  Effort  Thresholds,  Effort  Data 
Corrective  Actions 

Effort  Thresholds  Exceeded  Implies  Corrective  Actions  Identified 
At  ML2,  Thresholds  may  not  be  produced;  Effort  is  “tracked”. 

The  PDSP  is  used  in  planning  and  estimating,  but  the  S  DP,  which  embodies  the 
PDSP  at  (ML3,  is  used  for  tracking  or  managing. _ 


Manage  Cost 
AF-0143 

To  manage  the  cost  of  software  work  products  and  identify  corrective  actions  if 
the  actual  cost  data  exceeds  thresholds. 

PT.Ac6,  IM.Ac? 

SW  Engineering  Group 

Software  Development  Plan,  Cost  Estimates,  Cost  Thresholds,  Cost  Data 
Corrective  Actions 

Cost  Thresholds  Exceeded  Implies  Corrective  Actions  Identified 
At  ML2,  Thresholds  may  not  be  produced;  Cost  is  “tracked”. 

The  PDSP  is  used  in  planning  and  estimating,  but  the  S  DP,  which  embodies  the 
PDSP  at  (ML3,  is  used  for  tracking  or  managing. _ 


Manage  Critical  Computer  Resources 
AF-0144 

To  manage  the  critical  computer  resources  of  software  project  and  identify 
corrective  actions  if  the  actual  critical  computer  resource  data  exceeds  thresholds. 
PT.Ac7,  IM.Ac8 
SW  Engineering  Group 

Software  Development  Plan,  Critical  Computer  Resource  Estimates,  Critical 
Computer  Resource  Thresholds,  Critical  Computer  Resource  Data 
Corrective  Actions 

Critical  Computer  Resource  Thresholds  Exceeded  Implies  Corrective  Actions 
Identified 

At  ML2,  Thresholds  may  not  be  produced;  Critical  Computer  Resources  are 
“tracked”. 

The  PDSP  is  used  in  planning  and  estimating,  but  the  S  DP,  which  embodies  the 
PDSP  at  (ML3,  is  used  for  tracking  or  managing. _ 
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Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Name 

ID 

Purpose 


Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Name 

JP 

Purpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 

Comments 


Manage  Critical  Paths 
AF-0145 

To  manage  the  critical  paths  of  the  project  based  on  the  software  development 
plan,  estimates,  and  thresholds. 

IM.Ac4,  IM.AcS,  IM.Ac9,  IC.Ac4 
Software  Manager 

Software  Development  Plan,  Software  Estimates,  Software  Thresholds 
Corrective  Actions 

Thresholds  Exceeded  Implies  Corrective  Actions  Identified 

At  ML2,  Thresholds  may  not  be  produced;  Critical  paths  may  be  “tracked”. 

The  PDSP  is  used  in  planning  and  estimating,  but  the  S  DP,  which  embodies  the 
PDSP  at  (MLS,  is  used  for  tracking  or  managing. 

The  S  DP  incorporates  the  schedule  and  identifies  critical  paths.  _ 


Develop  Software  Risk  Management  Plan 
AF-0146 

To  develop  a  comprehensive  plan  for  managing  the  risks  associated  with  the 
software  development  effort  and  identify  contingencies  and  alternative  corrective 
actions  to  take  should  the  risk  occur  or  reach  a  probability  threshold  of  occurring. 
IM.AclO 

SW  Engineering  Group,  Software  Managers 

Software  Development  Plan,  Software  Risks,  Software  Estimates,  Software 
Thresholds,  Risk  Analysis,  Risk  Data 
Software  Risk  Management  Plan 

Software  Risk  Management  Plan  Managed  &  Controlled 
This  plan  is  part  of  the  S  DP;  Corrective  Actions  identified  in  managing  the 
roject  may  come  from  this  plan.  _ _ _ 


Manage  Risks 
AF-0147 

To  manage  the  risks  associated  with  the  software  development  effort  and  identify 
corrective  actions  to  take  based  on  the  risk  management  plan.. 

PT.AclO,  IM.AclO 
SW  Engineering  Group 

Software  Development  Plan,  Software  Risk  Management  Plan,  Software  Risks, 
Software  Thresholds,  Risk  Analysis,  Risk  Data 
Corrective  Actions 

Software  Risks  Occur  OR  Thresholds  Exceeded)  Implies 
Corrective  Actions  Identified 

At  ML2,  Thresholds  may  not  be  produced;  Risks  may  be  “tracked”. 

The  PDSP  is  used  in  planning  and  estimating,  but  the  S  DP,  which  embodies  the 
PDSP  at  (ML3,  is  used  for  tracking  or  managing. _ _ 
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Name 

ID 

Purpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Name 

ID 

Purpose 

Correlates  to 
gents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Review  Project  Periodic 
AF-0148 

To  determine  if  actions  are  needed  to  bring  the  project’s  performance  in  line  with 
plans,  estimates,  and  business,  customer,  or  end-user  needs. 

1.2.C,  5.4.a,  PP.Ac4,  PT.Acl2,  PT.AclS,  SM.AcT,  SM.Ac9,  IM.Acll,  Ve 
Reviewers 

Plans,  Status,  Activities,  Estimates,  Project  Data  Analysis,  Process  Data  Analysis, 
Business  Needs,  Customer  Needs 
Corrective  Actions,  Reports 

Corrective  Actions  (Documented  AND  Assigned  AND  Reviewed) 

Corrective  Actions  are  closed  under  AF-01 16,  Take  Corrective  Action 


Review  Allocated  Requirements 
AF-0149 

To  ensure  system  requirements  allocated  to  software  are  feasible,  appropriate, 
testable,  clear,  and  properly  stated. 

RM.Acl,  RM.Ac3,  PE.Ac2 
Reviewers 

Allocated  Requirements,  Criteria,  PDSP 

Approved  Requirements,  Problem  Allocated  Requirements 

Allocated  Requirements  Documented 

Criteria  NOT  Met  Implies  Problem  Allocated  Requirements  Identified 
At  ML2,  PDSP  may  not  be  formalized. _ 


Name 

Correct  Allocated  Requirements 

ID 

AF-01 50 

Purpose 

To  add  missing  requirements  or  correct  incomplete  or  problematic  requirements, 
such  as  one  that  are  not  feasible,  appropriate,  testable,  clear,  or  properly  stated. 

Correlates  to 

RM.Acl,  PE.Ac2 

Agents 

SW  Engineering  Group,  System  Requirements  Group 

Inputs 

Problem  Allocated  Requirements,  System  Requirements,  PDSP 

Outputs 

Corrected  Allocated  Requirements 

Entrance  Criteria 

System  Requirements  Documented  AND  (Managed  &  Controlled  OR  In  CM) 

Exit  Criteria 

Problem  Allocated  Requirements  Corrected 

Comments 

At  ML2,  PDSP  may  not  be  formalized. 

Name 

Requirements  Analysis 

ID 

AF-0151 

Purpose 

To  analyze  the  requirements  allocated  to  software  and  develop  the  sottwarc 
requirements  for  the  project. 

Correlates  to 

PE.Ac2 

Agents 

Analyzers 

Inputs 

Allocated  Requirements,  PDSP,  Analysis  Methods 

Outputs 

Entrance  Criteria 
Exit  Criteria 

Software  Requirements 

Comments 

At  ML2,  PDSP  may  not  be  formalized. 
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Name 

ID 

Purpose 

Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 

Comments 


Plan  Integration  Tests 
AF-0159 

To  develop  the  integration  testing  strategy  to  ensure  the  software  code 
components  work  and  meet  software  requirements  of  the  software  product. 
PE.Ac6 

Integration  Test  Planners,  Testers 

Software  Requirements  Document,  Software  Development  Plan,  PDSP 
Integration  Test  Plans,  Integration  Test  Procedures,  Integration  Test  Cases 

Integration  Test  Plans,  Integration  Test  Procedures,  Integration  Test  Cases) 
(Managed  &  Controlled  AND  Reviewed  by  Testers) 

At  ML2,  PDSP  may  not  be  formalized. 
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ID 

Purpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Name 

ID 

Purpose 

Correlates  to 
gents 
nputs 

Outputs 
ntrance  Criteria 
xit  Criteria 

Comments 


ID 

rpose 

Correlates  to 
gents 
nputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 

Comments 


Perform  System  Tests 
AF-0162 

To  test  the  system  using  plans,  procedures,  and  cases  developed  to  ensure 
components  work  together  as  a  system  and  meet  the  requirements  of  the  product. 
PE.Ac? 

Testers,  Customers 

Integrated  Components,  System  Test  Plans,  System  Test  Procedures,  System  Test 
Cases,  PDSP 

System  Test  Data,  System  Test  Results 
Software  Components  Passed  Software  Testing 

At  ML2,  PDSP  may  not  be  formalized. _ 


Develop  Software  Documentation 
AF-0163 

To  develop  the  documentation  used  to  describe  the  software  system. 

PE.AcS 

Documenters 

Software  Development  Plan,  Software  Requirements  Document,  Methods,  Tools, 
Software  Baselines,  PDSP 
Software  Documentation 

Software  Documentation  (Peer  Reviewed  AND  Managed  &  Controlled) 

Software  Documentation  (Reviewed  AND  Approved)  by  Customer 

At  ML2,  PDSP  may  not  be  formalized. _ 


Maintain  Software  Documentation 
AF-0164 

To  maintain  the  documentation  used  to  describe  the  software  system. 

PE.AcS 

Documenters 

Software  Documentation,  Change  Actions,  Software  Development  Plan,  Software 
Requirements  Document,  Methods,  Tools,  Software  Baselines,  PDSP 
Software  Documentation 

Software  Documentation  (Peer  Reviewed  AND  Managed  &  Controlled) 

Software  Documentation  (Reviewed  AND  Approved)  by  Customer 
At  ML2,  PDSP  may  not  be  formalized. 
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Name  Maintain  Consistency 

ID  AF-0165 

Purpose  To  maintain  consistency  from  allocated  requirements  through  software 

requirements,  architectural  and  detail  designs,  coding,  testing,  and  documentation. 

Correlates  to  PE. Ac  1 0 

Agents  Workers 

Inputs  Software  Work  Products,  Software  Documentation 

Outputs  Corrective  Actions 

Entrance  Criteria 

Exit  Criteria  Software  Work  Products,  Software  Documentation  NOT  Consistent 

Implies  Corrective  Actions  Identified 

Comments  _ _ 
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Name 

ID 

Purpose 


Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Manage  Schedule 
AF-0169 

To  manage  the  schedule  of  the  project  and  identify  corrective  actions  if  the 
schedule  exceeds  thresholds.  Another  aspect  of  this  requirement  is  to  manage  the 
critical  dependencies  between  the  engineering  group  and  other  affected  groups. 
PT.Ac8,  IC.Ac4,  IM.Ac9 
SW  Engineering  Group,  Affected  Groups 

Software  Development  Plan,  Inter  Group  Coordination  Plan,  Schedule  Estimates, 
Schedule  Thresholds,  Schedule  Data 
Corrective  Actions 

Schedule  Thresholds  Exceeded  Implies  Corrective  Actions  Identified 

Inter  Group  Coordination  Plan  contains  the  critical  dependencies  between  the  SW 

Engineering  Group  and  other  Affected  Groups. 

At  ML2,  Thresholds  may  not  be  produced;  Schedule  is  “tracked”. 

The  PDSP  is  used  in  planning  and  estimating,  but  the  S  DP,  which  embodies  the 
PDSP  at  (ML3,  is  used  for  tracking  or  managing. 


Name 

Plan  Peer  Review 

ID 

AF-0170 

Purpose 

To  plan  a  peer  review  of  software  work  products  during  the  software  lifecycle. 

Correlates  to 

PR.Acl 

Agents 

Planners 

Inputs 

Software  Development  Plan,  Software  Work  Products 

Outputs 

Entrance  Criteria 

Peer  Review  Plan 

Exit  Criteria 
Comments 

Software  Work  Products  Identified 

Name 

Develop  Measurement  Analysis  Strategy 

ID 

AF-0171 

Purpose 

To  develop  a  strategy  for  measuring  and  analyzing  process  quality  data. 

Correlates  to 

QP.Ac3 

Agents 

Workers 

Inputs 

PDSP,  Identified  Software  Work  Products,  Product  Indicators 

Outputs 

Measurement  Analysis  Strategy 

Entrance  Criteria 

Exit  Criteria 

Comments 

A-59 
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Name  Analyze  OSSP 

ID  AF-0179 

Purpose  To  analyze  the  organization’s  standard  software  process  and  associated 

technologies  to  identify  changes  that  would  benefit  the  organization. 

Correlates  to  TC.Ac4,  TC.Ac7 

Agents  TCM  Group 

Inputs  OSSP,  Organization  Current  Technologies,  Technology  Change  Requests 

Outputs  Technology  Analysis 

Entrance  Criteria 

Exit  Criteria  Technology  Analysis  Documented 

Comments  Technology  Analysis  includes  proposed  changes,  expected  outcomes,  proposed 

pilots,  etc. _ _ 


Name 

Select  Technology 

ID 

AF-0180 

Purpose 

To  select  which  technology  change  requests  to  approve  based  on  the 
organization’s  standard  software  process  and  technology  change  plan. 

Correlates  to 

TC.Ac5 

Agents 

TCM  Group,  Senior  Leaders 

Inputs 

Technology  Change  Requests,  OSSP,  Organization  Current  Technologies, 
Selection  Criteria,  TCM  Plan 

Outputs 

Technology  Change  Actions,  Technology  Requirements,  Technology  Plans 

Entrance  Criteria 

Selection  Criteria  (Predefined  AND  Approved) 

Exit  Criteria 

Technology  Change  Actions,  Technology  Requirements,  Technology  Plans) 

Comments 

Documented  AND  (Reviewed  AND  Approved  by  Senior  Leaders) 

Name 

Acquire  Technology 

ID 

AF-0181 

Purpose 

To  acquire  the  selected  technology  based  on  the  actions,  requirements  and  plans. 

Correlates  to 

TC.Ac5 

Agents 

TCM  Group,  Senior  Leaders 

Inputs 

Technology  Change  Actions,  Technology  Requirements,  Technology  Plans 

Outputs 

New  Technology 

Entrance  Criteria 

Exit  Criteria 

Comments 

Name 

Conduct  Technology  Pilot 

ID 

AF-0182 

Purpose 

To  conduct  a  pilot  with  a  newly  acquired  technology  to  evaluate  it  before 
implementing  it  across  the  organization. 

Correlates  to 

TC.Ac6 

Agents 

TCM  Group,  Technology  Users 

Inputs 

New  Technology,  Pilot  Plan 

Outputs 

Pilot  Analysis,  Implementation  Decision 

Entrance  Criteria 

Pilot  Plan  (Reviewed  AND  Approved  by  Technology  Users) 

Exit  Criteria 
Comments 

Pilot  Analysis  Documented 
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Name 

ID 

Purpose 
Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Name 

ID 

Purpose 

Correlates  to 
\gents 
Inputs 
Outputs 

Entrance  Criteria 
^xit  Criteria 
Comments 


Coordinate  Process  Improvement  Activities 
AF-0183 

To  coordinate  process  improvement  activities  across  the  organization. 
PC.Ac2,  PC.Ac4 

SEPG,  Organization  Members,  Senior  Leaders 
Process  Improvement  Plan 
Process  Improvement  Activities 


Name 

Review  Process  Improvement  Proposal 

ID 

AF-0184 

Purpose 

To  approve/disapprove  improvement  proposals  based  on  capability  baselines  and 
goals,  and  to  identify  associated  actions  to  implement  them. 

Correlates  to 

PC.Ac2,  PC.AcS 

Agents 

SEPG,  Senior  Leaders 

Inputs 

Improvement  Proposal,  Process  Capability  Baseline,  Organization  Improvement 
Goals,  Review  Criteria,  Review  Procedure 

Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 

Process  Improvement  Actions,  Rationale 

Name 

Develop  Action  Plan 

m 

AF-0185 

Purpose 

To  develop  an  action  plan  based  on  approved  improvement  proposals 

Correlates  to 

3.2.a,  PF.Acl,  PC.Ac4,  PC.Ac6 

Agents 

Improvement  Team,  Process  Owners,.  Senior  Leaders 

Inputs 

Improvement  Actions,  Software  Process  Improvement  Plan,  Improvement  Goals 

Outputs 

Process  Improvement  Action  Plan 

Entrance  Criteria 

Exit  Criteria 

Comments 

Pilot  Process  Improvement 
AF-0I86 

To  test  new  processes  in  limited  use,  and  evaluate  them  for  transfer  to  the  rest  of 
the  organization. 

S.l.b,  PF.Ac5,  PC.Ac4,  PC.Ac? 

Evaluators,  Process  Owners 

Action  Plan,  Pilot  Process,  Acceptance  Criteria 

Approved  Process,  Actions 


Actions  address  updating  OSSP  &  PDSP,  in  addition  to  implementation 
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Name 

ID 

Purpose 
Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 
Comments 


Implement  Process 
AF-0187 

To  implement  process  improvements  in  the  organization. 
2.2.a,  5.1. a,  5.2.b,  5.3.b,  5.4.b,  PC.Ac4,  PC.AcS 
Implementors,  Process  Owners 
Process,  Action  Plan,  Actions 
Improved  Process 


Closely  related  to  AF-0130  &  AF-0131  for  PDSP  and  AF-0191  &  AF-0192  for 
OSSP.  This  requirement  relates  to  actually  using  a  new  process. _ 


Name 

Maintain  SPI  Activity  Records 

ID 

AF-0188 

Purpose 

To  document  and  maintain  records  of  successful  and  failed  improvement  efforts. 

Correlates  to 

PC.Ac4,  PC.Ac9 

Agents 

SEPG 

Inputs 

Process  Improvement  Activities,  Improvement  Results,  Improvement  Data, 
Improvement  Data  Analysis,  Improvement  Plans 

Outputs 

Entrance  Criteria 

Process  Improvement  Records,  Process  Improvement  Reports 

Exit  Criteria 

Process  Improvement  Records,  Process  Improvement  Reports) 

Available  AND  Communicated 

Comments 

Name 

Release  Product 

ID 

AF-0189 

Purpose 

To  build  and  release  a  product  to  the  customer. 

Correlates  to 

CM.Ac2,  CM.Ac3,  CM.Ac7 

Agents 

CM  Group,  SCCB,  SW  Engineering  Group 

Inputs 

CM  Plan,  Software  Baselines 

Outputs 

Software  Product 

Entrance  Criteria 

SCCB  Approval 

Exit  Criteria 
Comments 

Software  Product  Built  Only  from  Software  Baselines 

Name 

Record  SCI  Status 

ID 

AF-0190 

Purpose 

To  document  and  maintain  the  status  of  software  configuration  items. 

Correlates  to 

CM.Ac2,  CM.Ac8,  CM.Ac9 

Agents 

CM  Group 

Inputs 

CM  Plan,  Software  Baselines 

Outputs 

Entrance  Criteria 

Status  Reports 

Exit  Criteria 
Comments 

Status  Reports  Available  AND  Communicated 
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Name 

ID 

Purpose 
Correlates  to 
\geiits 
nputs 

Outputs 

Entrance  Criteria 
ixit  Criteria 

Comments 


Name 

ID 

Purpose 
Correlates  to 
Agents 
Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 

Comments 


Develop  OSSP 
AF-0191 

To  develop  the  organization  standard  software  process. 

5.1. a,  PF.Co2,  PF.Co3,  PF.AcS,  PD.Acl,  PD.Ac2 
SEPG,  Senior  Leaders,  Process  Owners 

Software  Policies,  Process  Standards,  Product  Standards,  Customer  Standards, 

Benchmark  Processes,  Technology 

OSSP 

OSSP  Documented 

OSSP  (Reviewed  AND  Approved)  by  (Senior  Leaders  AND  SEPG) 

OSSP  -  Organization  Standard  Software  Process 

Senior  Leaders  are  input  to  meet  the  Organization  Process  Focus  Commitment  2 
&  3.  These  state  that  senior  leaders  sponsor  and  oversee  the  organization’s 
activities  for  software  process  development  and  improvement. 

For  an  organization  that  has  as  OSSP,  this  requirement  may  refer  to  developing 
new  processes  for  the  OSSP  and  the  its  use  by  the  organization. _ 


Maintain  OSSP 
AF-0192 

To  maintain  the  organization  standard  software  process. 

5.1.a,  PF.Co2,  PF.Co3,  PF.Ac3,  PD.Acl,  PD.Ac2,  DP.Ac6,  TC.Ac7 
SEPG,  Senior  Leaders,  Process  Owners 

OSSP  Change  Actions,  Software  Policies,  Process  Standards,  Product  Standards, 

Customer  Standards,  Benchmark  Processes,  Technology 

OSSP 

OSSP  Documented 

OSSP  (Reviewed  AND  Approved)  by  (Senior  Leaders  AND  SEPG) 

OSSP  -  Organization  Standard  Software  Process 

Senior  Leaders  are  input  to  meet  the  Organization  Process  Focus  Commitment  2 
&  3.  These  state  that  senior  leaders  sponsor  and  oversee  the  organization’s 
activities  for  software  process  development  and  improvement. 

OSSP  Change  Actions  may  come  from  Defect  Prevention  Analysis. 

OSSP  Change  Actions  may  come  from  technology  changes  associated  with  the 
Technology  input.  _ 
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Name 

ID 

Purpose 
Correlates  to 
Agents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 

Comments 


Name 

ID 

Purpose 

Correlates  to 
gents 
Inputs 
Outputs 

Entrance  Criteria 
Exit  Criteria 

Comments 


Name 

ID 

Purpose 

Correlates  to 

Agents 

Inputs 

Outputs 

Entrance  Criteria 
Exit  Criteria 

Comments 


Develop  Software  LifeCycle  Description 
AF-0193 

To  develop  descriptions  of  the  approved  software  lifecycles. 

PP.Ac5,  PF.Co2,  PF.Co3,  PD.Ac3 
SEPG,  Senior  Leaders,  Process  Owners 
Software  Lifecycles,  Documentation  Standards 
Software  LifeCycle  Descriptions 

Software  LifeCycle  Descriptions  Documented 
(Reviewed  AND  Approved)  by  (Senior  Leaders  AND  SEPG) 

Senior  Leaders  are  input  to  meet  the  Organization  Process  Focus  Commitment  2 
&  3.  These  state  that  senior  leaders  sponsor  and  oversee  the  organization’s 
activities  for  software  process  development  and  improvement. 


Develop  Tailoring  Guidelines 
AF-0194 

To  develop  guidelines  for  tailoring  the  organization  standard  software  process  for 
use  on  a  project. 

PF.Co2,  PF.Co3,  PD.Ac4 

SEPG,  Senior  Leaders,  Process  Owners 

OSSP,  Software  LifeCycle  Descriptions,  Documentation  Standards 
Tailoring  Guidelines 

Tailoring  Guidelines  Documented 

(Reviewed  AND  Approved)  by  (Senior  Leaders  AND  SEPG) 

Senior  Leaders  are  input  to  meet  the  Organization  Process  Focus  Commitment  2 
&  3.  These  state  that  senior  leaders  sponsor  and  oversee  the  organization’s 
activities  for  software  process  development  and  improvement. _ _ 


Maintain  Tailoring  Guidelines 
AF-0195 

To  maintain  guidelines  for  tailoring  the  organization  standard  software  process  for 
use  on  a  project. 

PF.Co2,  PF.Co3,  PD.Ac4 

SEPG,  Senior  Leaders,  Process  Owners 

Change  Actions,  OSSP,  Software  LifeCycle  Descriptions,  Documentation 
Standards 

Tailoring  Guidelines 
Tailoring  Guidelines  Documented 

(Reviewed  AND  Approved)  by  (Senior  Leaders  AND  SEPG) 

Senior  Leaders  are  input  to  meet  the  Organization  Process  Focus  Commitment  2 
&  3.  These  state  that  senior  leaders  sponsor  and  oversee  the  organization’s 
activities  for  software  process  development  and  improvement. _ 
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Name 

Maintain  Software  LifeCycle  Description 

ID 

AF-0196 

Purpose 

To  maintain  descriptions  of  the  approved  software  lifecycles. 

Correlates  to 

PP.AcS,  PF.Co2,  PF.Co3,  PD.Ac3 

Agents 

SEPG,  Senior  Leaders,  Process  Owners 

Inputs 

Software  Lifecycles,  Change  Actions,  Documentation  Standards 

Outputs 

Entrance  Criteria 

Software  LifeCycle  Descriptions 

Exit  Criteria 

Software  LifeCycle  Descriptions  Documented 
(Reviewed  AND  Approved)  by  (Senior  Leaders  AND  SEPG) 

Comments 

Senior  Leaders  are  input  to  meet  the  Organization  Process  Focus  Commitment  2 
&  3.  These  state  that  senior  leaders  sponsor  and  oversee  the  organization’s 
activities  for  software  process  development  and  improvement. 
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A-34 


A 


Acceptance 

Perform  Supplier  Acceptance  Tests . A-28 

Access 

Provide  Customer  Access . A-39 

Acquire 

Acquire  Technology . A-62 

Action 

Coordinate  Prevention  Action . A-61 

Develop  Action  Plan . A-63 

Take  Corrective  Actions . A-43 

Activities 

Assess  Member  Activities . A-18 

Coordinate  Process  Improvement  Activities . A-63 

Coordinate  Technical  Activities . A-58 

Determine  Partnering  Activities . A-34 

Track  Technical  Activities . A-43 

Activity 

Maintain  SPI  Activity  Records . A-64 

Measure  Activity . A-41 

Review  Activity . A-44 

Adequate 

Adequate  Funding . A-25 

Adequate  Resources . A-25 

Adequate  Training . A-25 

Aggregate 

Aggregate  Data . A-10 

Align 


Align  Plans 
Allocate 

Allocate  Quality  Goals . A-60 

Allocate  Requirements . A-26 

Allocated 

Correct  Allocated  Requirements . A-53 

Review  Allocated  Requirements . A-53 

Alternatives 

Evaluate  Alternatives . A-20 

Analysis 

Develop  Measurement  Analysis  Strategy . A-59 

Requirements  Analysis . A-53 

Analyze 

Analyze  Data . A-30 

Analyze  OSSP . A-62 

Analyze  PDSP . A-60 

Analyze  Risks . A-50 

Approach 

Develop  Breakthrough  Approach . A- 14 

Architecture 

Develop  Software  Architecture  Design . A-54 

Areas 

Identify  Technology  Change  Areas . A-61 

Assess 

Assess  Community  Impact . A-33 

Assess  Community  Involvement . A- 13 

Assess  Member  Activities . A-18 

Assess  Member  Development . A- 14 

Assess  Member  Facilities . A-18 
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Assess  Member  Services . A-18 

Assess  Member  Well-Being . A-14 

Assess  Requirements  Change . A-27 

Assess  Workforce  Motivation . A-36 

Assess  Workforce  Satisfaction . A-35 

Assessment 

Process  Assessment . A-33 

Audit 

Audit  Baseline . A-44 


B 


Baseline 

Audit  Baseline . A-44 

Change  Baseline . A-29 

Maintain  Process  Capability  Baseline . A-60 

Benchmarking 

Determine  Benchmarking  Data  Criteria . A-9 

Determine  Benchmarking  Requirements . A-9 

Set  Benchmarking  Priorities . A-9 

Benefits 

Determine  Benefits . A-12 

Breakthrough 

Develop  Breakthrough  Approach . A-14 

Build 

Build  Organizational  Capabilities . A-10 

Build  Supplier  Relationship . A-21 

Build  Workforce  Satisfaction . A- 17 


Build  Workforce  Well-Being . A-17 

C 


Capabilities 

Build  Organizational  Capabilities . A-10 

Capability 

Maintain  Process  Capability  Baseline . A-60 

Cause 

Determine  Root  Cause . A-20 

Change 

Assess  Requirements  Change . A-27 

Change  Baseline . A-29 

Change  Supplier  Commitment . A-42 

Handle  Change  Requests . A-29 

Identify  Technology  Change  Areas . A-61 

Citizenship 

Set  Citizenship  Goals . A-33 

CM 

Establish  CM  Library  System . A-28 

Code 

Develop  Software  Code . A-55 

Commitment 

Change  Supplier  Commitment . A-42 

Make  Commitment . A -43 

Communicate 

Communicate  Information . A-38 

Communicate  Leadership  Information . A-32 


A^70 


Communicate  Supplier  Requirements . A-37 

Community 

Assess  Community  Impact . A-33 

Assess  Community  Involvement . A-13 

Improve  Community  Involvement . A-13 

Plan  Community  Involvement . A-33 

Compensate 

Compensate  Member . A-16 

Complaint 

Evaluate  Customer  Complaint . A-40 

Record  Customer  Complaint . A-40 

Computer 

Estimate  Critical  Computer  Resources . A-49 

Manage  Critical  Computer  Resources . A-51 

Conduct 

Conduct  Task  Preparation  Meeting . A-61 

Conduct  Technology  Pilot . A-62 

Conduct  Training  Waiver  Procedure . A-46 

Configuration 

Identify  Software  Configuration  Items . A-29 

Consistency 

Maintain  Consistency . A-58 

Coordinate 

Coordinate  Prevention  Action . A-61 

Coordinate  Process  Improvement  Activities . A-63 

Coordinate  Technical  Activities . A-58 


Correct 

Correct  Allocated  Requirements . A-53 

Corrective 

Take  Corrective  Actions . A-43 

Cost 

Estimate  Cost . A-48 

Manage  Cost . A-51 

Course 

Develop  Training  Course . A-45 

Maintain  Training  Course . A-46 

Criteria 

Determine  Benchmarking  Data  Criteria . A-9 

Develop  Design  Criteria . A-54 

Critical 

Estimate  Critical  Computer  Resources . A-49 

Manage  Critical  Computer  Resources . A-51 

Manage  Critical  Paths . A-52 

Customer 

Determine  Customer  Data  Requirements . A-8 

Determine  Customer  Expectations . A-22 

Determine  Customer  Groups . A-38 

Determine  Customer  Requirements . A-21 

Determine  Future  Customer  Expectations . A-23 

Determine  Future  Customer  Requirements . A-22 

Evaluate  Customer  Complaint . A-40 

Gather  Customer  Feedback  Data . A-40 
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Gather  Customer  Information . A-39 

Provide  Customer  Access . A-39 

Record  Customer  Complaint . A-40 


D 


Data 

Aggregate  Data . A- 10 

Analyze  Data . A-30 

Determine  Benchmarking  Data  Criteria . A-9 

Determine  Customer  Data  Requirements . A-8 

Gather  Customer  Feedback  Data . A-40 

Gather  Internal  Data . A-38 

Project  Key  Indicator  Data . A-12 

Database 

Maintain  Software  Process  Database . A-41 

Delivery 

Plan  Training  Delivery . A-35 

Derive 

Derive  Schedule . A-49 

Description 

Develop  Software  LifeCycle  Description . A-66 

Maintain  Software  LifeCycle  Description . A-67 

Design 

Design  Process . A-18 

Design  Service . A- 19 

Develop  Design  Criteria . A-54 

Develop  Software  Architecture  Design . A-54 


Develop  Software  Detail  Design . A-54 

Evaluate  Job  Design . A-31 

Improve  Job  Design . A- 15 

Detail 

Develop  Software  Detail  Design . A-54 

Determine 

Determine  Benchmarking  Data  Criteria . A-9 

Determine  Benchmarking  Requirements . A-9 

Determine  Benefits . A-12 

Determine  Customer  Data  Requirements . A-8 

Determine  Customer  Expectations . A-22 

Determine  Customer  Groups . A-38 

Determine  Customer  Requirements . A-21 

Determine  Future  Customer  Expectations . A-23 

Determine  Future  Customer  Requirements . A-22 

Determine  Indicators . A-30 

Determine  Key  Performance  Drivers . A-11 

Determine  Key  Supplier  Requirements . A-37 

Determine  Partnering  Activities . A-34 

Determine  Root  Cause . A-20 

Determine  Status . A-26 

Develop 

Develop  Action  Plan . A-63 

Develop  Breakthrough  Approach . A-14 

Develop  Design  Criteria . A-54 

Develop  Listening  Strategies . A-23 
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Develop  Measurement  Analysis  Strategy . A-59 

Develop  Organizational  Values . A-7 

Develop  OSSP . A-65 

Develop  PDSP . A-47 

Develop  Project  Proposal . A-27 

Develop  Softvv'are  Architecture  Design . A-54 

Develop  Software  Code . A-55 

Develop  Software  Detail  Design . A-54 

Develop  Software  Documentation . A-57 

Develop  Software  LifeCycIe  Description . A-66 

Develop  Software  Requirements . A-42 

Develop  Software  Requirements  Document . A-54 

Develop  Software  Risk  Management  Plan . A-52 

Develop  Tailoring  Guidelines . A-66 

Develop  Training  Course . A-45 

Development 

Assess  Member  Development . A-14 


Deviations 


Handle  Deviations . A-28 

Directions 

Set  Directions . A-7 

Document 

Develop  Software  Requirements  Document . A-54 

Documentation 

Develop  Software  Documentation . A-57 

Maintain  Software  Documentation . A-57 


Drivers 

Determine  Key  Performance  Drivers . A-11 

E 


Effectiveness 

Evaluate  Mission  Effectiveness . A-23 

Effort 

Estimate  Effort . A-48 

Manage  Effort . A-51 

Environment 

Improve  Work  Environment . A- 17 

Review  Work  Environment . A- 17 

Establish 

Establish  CM  Library  System . A-28 

Establish  System  Requirements . A-58 

Estimate 

Estimate  Cost . A-48 

Estimate  Critical  Computer  Resources . A-49 

Estimate  Effort . A-48 

Estimate  Size . A-48 

Evaluate 

Evaluate  Alternatives . A-20 

Evaluate  Customer  Complaint . A-40 

Evaluate  Improvement  Linkage . A-27 

Evaluate  Job  Design . A-31 

Evaluate  Measurement  Scale . A-24 

Evaluate  Member . A-16 
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Evaluate  Mission  Effectiveness . A-23 

Evaluate  Process . A-29 

Evaluate  Product  Implementation . A-36 

Evaluate  Service  Implementation . A-36 

Evaluate  Training . A-12 

Evaluate  Work  Organization . A-32 

Evaluation 

Independent  Training  Evaluation . A-46 

Event-Driven 

Review  Project  Event-Driven . A-41 

Expectations 

Determine  Customer  Expectations . A-22 

Determine  Future  Customer  Expectations . A-23 

Set  Expectations . A-7 

External 

Gather  External  Information . A-34 


F 


Facilities 

Assess  Member  Facilities . A-18 

Feedback 

Gather  Customer  Feedback  Data . A-40 

Follows 

Follows  Policy . A-24 

Follows  Procedure . A-26 

Funding 

Adequate  Funding . A-25 


Future 

Determine  Future  Customer  Expectations . A-23 

Determine  Future  Customer  Requirements . A-22 


G 


Gather 

Gather  Customer  Feedback  Data . A-40 

Gather  Customer  Information . A-39 

Gather  External  Information . A-34 

Gather  Internal  Data . A-38 

Goals 

Allocate  Quality  Goals . A-60 

Set  Citizenship  Goals . A-33 

Set  Goals . A-13 

Group 

Resolve  Inter  Group  Issues . A-58 

Select  Group . A-38 

Groups 

Determine  Customer  Groups . A-38 

Guidelines 

Develop  Tailoring  Guidelines . A-66 

Maintain  Tailoring  Guidelines . A-66 


H 


Handle 

Handle  Change  Requests . A-29 

Handle  Deviations . A-28 
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A.19 


/ 


Identify 

Identify  Risks . A-49 

Identify  Software  Configuration  Items . A-29 

Identify  Software  Work  Products . A-47 

Identify  Technology  Change  Areas . A-61 

Identify  Training  Needs . A-35 

Impact 

Assess  Community  Impact . A-33 

Implement 

Implement  Process . A-64 

Implementation 

Evaluate  Product  Implementation . A-36 

Evaluate  Service  Implementation . A-36 

Improve 

Improve  Community  Involvement . A-13 

Improve  Job  Design . A-15 

Improve  Leadership  System . A- 10 

Improve  Measurement  Scale . A-24 

Improve  Organization  Structure . A- 11 

Improve  Training . A- 16 

Improve  Work  Environment . A- 17 

Improve  Work  Organization . A-15 

Improvement 

Coordinate  Process  Improvement  Activities . A-63 

Evaluate  Improvement  Linkage . A-27 


Maintain  Improvement  Program 

Pilot  Process  Improvement . A-63 

Review  Process  Improvement  Proposal . A-63 

Independent 

Independent  Training  Evaluation . A-46 

Indicator 

Project  Key  Indicator  Data . A-12 

Indicators 

Determine  Indicators . A-30 


Information 


Communicate  Information . A-38 

Communicate  Leadership  Information . A-32 

Gather  Customer  Information . A-39 

Gather  External  Information . A-34 

Integration 

Perform  Integration  Tests . A-56 

Plan  Integration  Tests . A-56 

InterGroup 

Resolve  Inter  Group  Issues . A-58 

Internal 

Gather  Internal  Data . A-38 

Involvement 

Assess  Community  Involvement . A-13 

Improve  Community  Involvement . A-13 

Plan  Community  Involvement . A-33 


A-75 


Issues 


Listening 


Resolve  Inter  Group  Issues . A-58 

Items 

Identify  Software  Configuration  Items . A-29 


J 


Job 

Evaluate  Job  Design . A-31 

Improve  Job  Design . A-15 


K 


Key 

Determine  Key  Performance  Drivers . A-11 

Determine  Key  Supplier  Requirements . A-37 

Project  Key  Indicator  Data . A- 12 


L 


Leadership 

Communicate  Leadership  Information . A-32 

Improve  Leadership  System . A- 10 

Library 

Establish  CM  Library  System . A-28 

Maintain  Software  Process  Library . A-45 

LifeCycle 

Develop  Software  LifeCycle  Description . A-66 

Maintain  Software  LifeCycle  Description . A-67 

Linkage 

Evaluate  Improvement  Linkage . A-27 


Develop  Listening  Strategies . A-23 

M 


Maintain 

Maintain  Consistency . A-58 

Maintain  Improvement  Program . A- 19 

Maintain  OSSP . A-65 

Maintain  Process  Capability  Baseline . A-60 

Maintain  Product  Standards . A-39 

Maintain  Service  Standards . A-39 

Maintain  Software  Documentation . A-57 

Maintain  Software  LifeCycle  Description . A-67 

Maintain  Software  Process  Database . A-41 

Maintain  Software  Process  Library . A-45 

Maintain  SPI  Activity  Records . A-64 

Maintain  Tailoring  Guidelines . A-66 

Maintain  Training  Course . A-46 

Maintain  Training  Records . A-45 

Make 

Make  Commitment . A -43 

Manage 

Manage  Cost . V-51 

Manage  Critical  Computer  Resources . \-51 

Manage  Critical  Paths . ^-52 

Manage  Effort .  ^-51 

Manage  Quality .  ^-60 
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Manage  Risks . A-52 

Manage  Schedule . A-59 

Manage  Size . A-50 

Management 

Develop  Software  Risk  Management  Plan . A-52 

Measure 

Measure  Activity . A-41 

Measure  Process . A-30 

Measure  Product . A-44 

Measure  Training  Quality . A-46 

Measurement 

Develop  Measurement  Analysis  Strategy . A-59 

Evaluate  Measurement  Scale . A-24 

Improve  Measurement  Scale . A-24 

Meeting 

Conduct  Task  Preparation  Meeting . A-61 

Member 

Assess  Member  Activities . A-18 

Assess  Member  Development . A-14 

Assess  Member  Facilities . A-18 

Assess  Member  Services . A-18 

Assess  Member  Well-Being . A-14 

Compensate  Member . A-16 

Evaluate  Member . A-16 

Recognize  Member . A-15 

Mission 


Evaluate  Mission  Effectiveness . A-23 

Motivation 

Assess  Workforce  Motivation . A-36 


N 

Needs 

Identify  Training  Needs . A-35 

O 


Objectives 

Set  Objectives . A- 11 

Set  Performance  Objectives . A-31 

Organization 

Evaluate  Work  Organization . A-32 

Improve  Organization  Structure . A-11 

Improve  Work  Organization . A-15 

Organizational 

Build  Organizational  Capabilities . A-10 

Develop  Organizational  Values . A-7 

Reinforce  Organizational  Values . A-32 

Review  Organizational  Performance . A-8 

Review  Organizational  Structure . A-8 

OSSP 

Analyze  OSSP . A-62 

Develop  OSSP . A-65 

Maintain  OSSP . A-65 
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p 


Partnering 

Determine  Partnering  Activities . A-34 

Paths 

Manage  Critical  Paths . A-52 

PDSP 

Analyze  PDSP . A-60 

Develop  PDSP . A-47 

Revise  PDSP . A-47 

Peer 

Plan  Peer  Review . A-59 

Perform 

Perform  Integration  Tests . A-56 

Perform  Supplier  Acceptance  Tests . A-28 

Perform  System  Tests . A-57 

Perform  Training . A-45 

Perform  Unit  Tests . A-55 

Performance 

Determine  Key  Performance  Drivers . A-11 

Review  Organizational  Performance . A-8 

Set  Performance  Objectives . A-31 

Periodic 

Review  Project  Periodic . A-53 

Pilot 

Conduct  Technology  Pilot . A-62 

Pilot  Process  Improvement . A-63 


Plan 

Develop  Action  Plan . A-63 

Develop  Software  Risk  Management  Plan . A-52 

Plan  Community  Involvement . A-33 

Plan  Integration  Tests . A-56 

Plan  Peer  Review . A-59 

Plan  Supplier  Work . A-44 

Plan  System  Tests . A-56 

Plan  Training  Delivery . A-35 

Plan  Unit  Tests . A-55 

Planning 

Project  Planning . A-42 

Strategic  Planning . .....A-31 

Plans 

Align  Plans . A-34 

Policy 

Follows  Policy . A-24 

Preparation 

Conduct  Task  Preparation  Meeting . A-61 

Prevention 

Coordinate  Prevention  Action . A-61 

Priorities 

Set  Benchmarking  Priorities . A-9 

Prioritize 

Prioritize  Risks . A-50 
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Procedure 


Project 


Conduct  Training  Waiver  Procedure . A-46 

Follows  Procedure . A-26 

Process 


Coordinate  Process  Improvement  Activities . A-63 


Design  Process . A-18 

Evaluate  Process . A-29 

Implement  Process . A-64 

Maintain  Process  Capability  Baseline . A-60 

Maintain  Software  Process  Database . A-41 

Maintain  Software  Process  Library . A-45 

Measure  Process . A-30 

Pilot  Process  Improvement . A-63 

Process  Assessment . A-33 

Review  Process  Improvement  Proposal . A-63 

Product 

Evaluate  Product  Implementation . A-36 

Maintain  Product  Standards . A-39 

Measure  Product . A-44 

Release  Product . A-64 

Review  Product . A-40 

Test  Product . A-19 

Products 

Identify  Software  Work  Products . A-47 

Program 

Maintain  Improvement  Program . A-19 


Develop  Project  Proposal . A-27 

Project  Key  Indicator  Data . A-12 

Project  Planning . A-42 

Review  Project  Event-Driven . A-41 

Review  Project  Periodic . A-53 

Proposal 

Develop  Project  Proposal . A-27 

Review  Process  Improvement  Proposal . A-63 

Provide 

Provide  Customer  Access . A-39 


Q 


Quality 

Allocate  Quality  Goals . A-60 

Manage  Quality . A-60 

Measure  Training  Quality . A-46 


R 


Recognize 

Recognize  Member . A- 15 

Record 

Record  Customer  Complaint . A-40 

Record  SCI  Status . A-64 

Records 

Maintain  SPI  Activity  Records . A-64 

Maintain  Training  Records . A-45 
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Reinforce 


Resolve 


Reinforce  Organizational  Values . A-32 

Reinforce  Training . A-35 

Relationship 

Build  Supplier  Relationship . A-21 

Release 

Release  Product . A-64 

Requests 

Handle  Change  Requests . A-29 

Requirements 

Allocate  Requirements . A-26 

Assess  Requirements  Change . A-27 

Communicate  Supplier  Requirements . A-37 

Correct  Allocated  Requirements . A-53 

Determine  Benchmarking  Requirements . A-9 

Determine  Customer  Data  Requirements . A-8 

Determine  Customer  Requirements . A-21 

Determine  Future  Customer  Requirements . A-22 

Determine  Key  Supplier  Requirements . A-37 

Develop  Software  Requirements . A-42 

Develop  Software  Requirements  Document . A-54 

Establish  System  Requirements . A-58 

Requirements  Analysis . A-53 

Review  Allocated  Requirements . A-53 

Research 

Do  Research . A-37 


Resolve  Inter  Group  Issues . A-58 

Resources 

Adequate  Resources . A-25 

Estimate  Critical  Computer  Resources . A-49 

Manage  Critical  Computer  Resources . A-51 

Review 

Plan  Peer  Review . A-59 

Review  Activity . A-44 

Review  Allocated  Requirements . A-53 

Review  Organizational  Performance . A-8 

Review  Organizational  Structure . A-8 

Review  Process  Improvement  Proposal . A-63 

Review  Product . A-40 

Review  Project  Event-Driven . A-41 

Review  Project  Periodic . A-53 

Review  Work  Environment . A- 17 

Revise 

Revise  PDSP . A-47 

Risk 

Develop  Software  Risk  Management  Plan . A-52 

Risks 

Analyze  Risks . A-50 

Identify  Risks . A-49 

Manage  Risks . A-52 

Prioritize  Risks . A-50 
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Root 

Determine  Root  Cause . A-20 

S 


Satisfaction 

Assess  Workforce  Satisfaction . A-35 

Build  Workforce  Satisfaction . A-17 

Scale 

Evaluate  Measurement  Scale . A-24 

Improve  Measurement  Scale . A-24 

Schedule 

Derive  Schedule . A-49 

Manage  Schedule . . . A-59 

SCI 

Record  SCI  Status . A-64 

Select 

Select  Group . A-38 

Select  Technology . A-62 

Service 

Design  Service . A-19 

Evaluate  Service  Implementation . A-36 

Maintain  Service  Standards . A-39 

Test  Service . A-20 

Services 

Assess  Member  Services . A- 18 

Set 

Set  Benchmarking  Priorities . A-9 


Set  Citizenship  Goals . A-33 

Set  Directions . A-7 

Set  Expectations . A-7 

Set  Goals . A-13 

Set  Objectives . A- 11 

Set  Performance  Objectives . A-31 

Size 

Estimate  Size . A-48 

Manage  Size . A-50 

Software 

Develop  Software  Architecture  Design . A-54 

Develop  Software  Code . A-55 

Develop  Software  Detail  Design . A-54 

Develop  Software  Documentation . A-57 

Develop  Software  LifeCycle  Description . A-66 

Develop  Software  Requirements . A-42 

Develop  Software  Requirements  Document . A-54 

Develop  Software  Risk  Management  Plan . A-52 

Identify  Software  Configuration  Items . A-29 

Identify  Software  Work  Products . A -47 

Maintain  Software  Documentation . \-57 

Maintain  Software  LifeCycle  Description . V-67 

Maintain  Software  Process  Database . V-41 

Maintain  Software  Process  Library .  \-45 

SPI 

Maintain  SPI  Activity  Records . V-M 


A-81 


Standards 


Perform  System  Tests 


A-57 


Maintain  Product  Standards . A-39 
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Appendix  B  -  Capability  Maturity  Model  Relations  to  Quality  Air  Force  and  Integrated 

Requirements 

1.0  Purpose 

The  overall  purpose  of  this  document  is  to  reference  the  Capability  Maturity  Model 
for  Software  (CMM)  to  the  Quality  Air  Force  (QAF)  criteria  by  identifying  the  integrated 
requirements  that  relate  the  two  models. 

2.0  Overview 

This  document  maps  the  CMM  to  the  QAF  criteria  through  the  integrated 
requirements  that  correlate  back  to  each  model.  Only  the  CMM  practices  that  have  a 
relationship  to  QAF  areas  are  included.  The  document  is  organized  to  mirror  the  maturity 
levels  and  key  process  areas  in  the  CMM.  The  related  area  of  the  QAF  criteria  is 
provided  along  with  the  name  and  ID  of  the  integrated  requirement  that  correlates  to  that 
CMM  practice  and  the  identified  QAF  areas. 
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3.0  Guide  to  Codes 


3.1  Capability  Maturity  Model  Codes. 

3.1.1  Key  Process  Areas  (KPAs): 

RM  Requirements  Management 

PP  Software  Project  Planning 

PT  Software  Project  Tracking  &  Oversight 

SM  Software  Subcontract  Management 

QA  Software  Quality  Assurance 

CM  Software  Configuration  Management 

PF  Organization  Process  Focus 

PD  Organization  Process  Definition 

TP  Training  Program 

IM  Integrated  Software  Management 

PE  Software  Product  Engineering 

IC  InterGroup  Coordination 

PR  Peer  Reviews 

QP  Quantitative  Process  Management 

SQ  Software  Quality  Management 

DP  Defect  Prevention 

TC  Technology  Change  Management 

PC  Process  Change  Management 

3.1.2  Other  Common  Features  (OCFs): 

Co  Commitment  to  Perform 

Ab  Ability  to  Perform 

Me  Measurement  and  Analysis 

Ve  Verifying  Implementation 
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3.2  Quality  Air  Force  Criteria  Codes 


1.0  Leadership 

1 . 1  Senior  Executive  Leadership 

1.2  Leadership  System  and  Organization 

1.3  Public  Responsibility  and  Citizenship 
2.0  Information  and  Analysis 

2. 1  Management  of  Information  and  Data 

2.2  Comparisons  and  Benchmarking 

2.3  Analysis  and  Use  of  Organization-Level  Data 
3.0  Strategic  Planning 

3.1  Strategy  Development 

3.2  Strategic  Deployment 

4.0  Human  Resource  Development  and  Management 

4.1  Human  Resource  Planning  and  Evaluation 

4.2  High  Performance  Work  Systems 

4.3  Member  Education,  Training,  and  Development 

4.4  Well  Being  and  Satisfaction 
5.0  Process  Management 

5.1  Design  and  Introduction  of  Products  and  Services 

5.2  Key  Process  Management:  Product  and  Service  Production 

and  Delivery 

5.3  Process  Management:  Support  Services 

5.4  Supplier  Performance  Management 
6.0  Performance  Results 

6.1  Product  and  Service  Quality 

6.2  Operational  Performance  and  Financial  Results 

6.3  Supplier  Performance  Results 
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7.0  Customer  Focus  and  Customer  Satisfaction 

7.1  Customer  Knowledge 

7.2  Customer  Management 

7.3  Customer  Satisfaction  Determination 

7.4  Customer  Satisfaction  Results 

7.5  Customer  Satisfaction  Comparison 


4.0  Reference 


CMM 


Me 


Me 


Related  to  OAF 


5.2.a,  5.3.b,  5.4.a,  6.2.a,  6.3.a 


2.2. a,  2.3.a,  3.2.b,  5.2.a,  5.3.b, 
6.1.a,6.2.a,6.3.a,7.2.b,  7.2.c, 

7.3. b,  7.4.a,  7.4.b,  7.5.a,  7.5.b 


Ve 

1.2.C 

Ve 

5.2.a,  5.3.b 

Ve 

1.2.C,  5.4.a 

Ve 

1.1.  b,  2.1.b,  2.2.b,  3.1.C,  4.1.b,  5.1.C, 

5.2. b,  5.3.C,  5.4.b,  7.1.C,  7.2.d,  7.3.c 

PP.Ac2 

5.1.a,5.2.a,5.3.b 

PP.Ac3 

5.1. a,  5.2.a,  5.3.b 

PP.Ac4 

I.2.C.  5.4.a 

Related 


Measure  Process 


I  Analyze  Data 


Review  Project  (Event  Driven) 


Take  Corrective  Actions 


Review  Project  (Periodic) 


Evaluate  Process 


PP.Ac5 


5.2.a,  5.3.b 


Project  Review 


Project  Plannin 


PP.Ac6 

5.1.a,5.2.a,5.3.b 

PP.Ac7 

3.1.b 

PP.Ac7 


5.2.a,  5.3.b 


Set  Objectives 


Project  Plannin 


PP.Acl4 

5.1.a,5.2.a,  5.3.b 

PP.AclS 

2.3. a,  6.1. a,  6.2.a 

PT.Acl 

5.1.a,5.2.a,  5.3.b 

PT.Ac2 

5.1.a,  5.2.a,5.3.b 

PT.Ac4 


Change  Supplier  Commitment 


PT.AcS 

5.2.a,  5.3.b 

Take  Corrective  Actions 

PT.Ac6 

5.2.a.  5.3.b 

Take  Corrective  Actions 

PT.Ac7 


PT.Ac8 

5.2.a,  5.3.b 

PT.Ac9 

5.2.a,  5.3.b 

PT.Acll 


PT.AC12 


PT.Acl3 


l.l.a,  2.2.a,  2.3.a,  3.2.b,  5 
5.4.a,  6.1. a,  6.2.a,  6.3.a,  7 
7.3.a.  7.3.b,  7.4.a,  7.4.b,  1 


5.4.a,  6.1.a,  6.3.a  _ 


1.2.C,  5.4.a  _ 


1.2.C,  5.4.a  _ 


5.3.b, 

7.2.C, 

7.5.b 


Take  Corrective  Actions 


Take  Corrective  Actions 


Take  Corrective  Actions 


Take  Corrective  Actions 


a 


[Measure  Product 


Project  Review 


Project  Review 


ID 


AF-0072 


AF-0073 


AF-0109 


AF-0116 


AF-Q148 


AF-0070 


AF-01 14 


AF-0114 


AF-0148 


AF-0114 


AF-0114 


AF-0014 


AF-0114 


AF-0114 


AF-0098 


AF-0114 


AF-0114 


AF-01 13 


AF-0116 


AF-0116 


AF-0116 


AF-0116 


AF-0116 


AF-0116 


AF-0073 


AF-01 18 


AF-0148 


AF-0148 


SM.Acl 

SM.Acl 


SM.Acl 


SM.Ac2 


SM.Ac2 


SM.AcS 


SM.Ac4 


SM.Ac6 


SM.Ac7 


SM.Ac9 


SM.Acl2 


SM.Acl  3 


QA.Acl 


QA.Ac2 


QA.Ac2 


QA.Ac3 


QA.Ac5 


5.4.b 


1.1. a,  1.2.C 


T.l.a 


5.4.a 


IS.l.b 


5.4.b 


1.2.C,  5.4.a 


1.2.C,  5.4.a 


5.4.a 


QA.Ac7 


QA.AcS 


CM.Acl 


CM.Ac2 


CM.Ac9 


PF.Co2 


PF.Co2 


PF.Co3 


PF.Co3 


PF.Acl 


PF.Acl 


PF.Ac2 


PF.Ac3 


PF.Ac3 


PF.Ac4 


PF.Ac4 


PF.AcS 


PF.Ac6 


PF.Ac7 


1.1. b,  2. 

5.2. b,  5. 


5.1. a,  5. 


5.4.a,  7. 


5.1.b 


5.1.a,  5. 


5.1.b 


5.4.a,  7. 


S.l.b 


5.4.a,  7. 


5.1. a,  5. 


5.4.a,  7. 


5.4.a,  7. 


5.1.a 


^l.a 


5.1.a 


B.l.a 


l.l.a,  1. 


3.2.a 


3.1. a,  4. 


5.1.a 


5.1.a 


l.l.a,  2. 
5.4.a,  6. 
7.3.a,  7. 


5.4.a,  6, 
5.1.b 


.3.b 


5.4.a,  7, 


l.b,  2.2.b, 
3.C,  5.4.b, 


2. a,  5.3.b 

2,a _ 


2.a,  5.3.b 


2,a _ 


2.a,  5.3.b 


2.a 


2.a 


2. a,  2.3.a, 
l.a,  6.2.a, 

3. b,  7.4.a, 


l.a,  6.3.a 


_ Determine  Partnering  Activities 

Determine  Key  Supplier 
_ Requirements _ 


Plan  Supplier  Work _ 


_ Process  Assessment 


Select  Grou 


_  Communicate  Supplier  Reqs 


Review  Product 


_ Change  Supplier  Commitment 


_ Project  Review _ 


Project  Review 


Perform  Supplier  Acceptance 
Tests 


3.1. C,  4. l.b,  5.1.C,  Evaluate  Process 

7.1. C,  7.2.d,  7.3.C _ 


Communicate  Information 


[Review  Product 


[Review  Product _ 


Communicate  Information 


Review  Product 


Communicate  Information 


_ Project  Plannin 


Communicate  Information 


Communicate  Information 


_ Develop  OSSP _ 


Maintain  OSSP 


Develop  OSSP 


Maintain  OSSP 


Process  Assessment 


_ Develop  Action  Plan 


_ Strategic  Plannin 


_ Develop  OSSP _ 


[Maintain  OSSP _ 


3.2. b,  5.2.a,  5.3.b,  Analyze  Data 

6.3. a,  7.2.b,  7.2.c, 


7.4.b,  7.5.a,  7.5.b 


Measure  Product _ 

Pilot  Process  Improvement 


Plan  Training  Delive 


Communicate  Information 


AF-0085 

'aF-0096 


AF-0119 


AF-0080 


AF-0100 


[AF-G095 


AF-0108 


AF-0113 


AF-0148 


AF-0148 


AF-0064 


AF-0070 


AF-0114 


AF-0097 


AF-0108 


AF-0114 


AF-0108 


[AF-0097 


AF-0108 


AF-0097 


AF-01 14 


[AF-0097 


AF-0097 


AF-0191 


AF-01 92 


AF-0191 


[AF-0192 


AF-0080 


AF-01 85 


AF-0075 


AF-0191 


AF-0192 


AF-0073 


AF-01 18 
'  AF-01 86 


AF-0088 


[AF-0097 
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PD.Acl  5.1. a 


PD.Acl  5.1.a 


PD.Acl 


PD.Ac2  5.1. a 


PD.Ac2  5.  La 


PD.Ac2  5.  La 


PD.Ac5  2.3.a,6.La,6.2.a 


TP.Acl  4.3.b 


TP.Acl  4.3.b 


TP.Acl  r5.La,5.2.a,5.3.b 


TP.Ac2  3.  La,  4.  La 


TP.Ac3 


TP.Ac4 


TP.Me2 


TP.Ve2 


TP.Ve3 


IM.Ac3 


IM.Ac4 


IM.Ac4 


IM.Ac4 


IM.Ac5 


IM.Ac5 


IM.Ac5 


IM.Acll 


IM.Acll 


IM.Acll 


PE.Ac3 


PE.Ac3 


PE.Ac3 


PE.Ac9 


PE.Ac9 


PE.Mel 


PE.Mel 


4.3.b 


4.3. 


4.3.a,  4. 


k3.a,4. 


l4.3.a,  4. 


5.  La,  5. 


LLa,2. 
5.4.a,  6. 
7.3.a,7. 


5.  La,  5. 


5.4.a,  6. 


LLa,2. 
5.4.a,  6. 
7.3.a,  7. 


l57La,5. 


5.4.a,  6. 


L2.C 


1.1. b,  2. 

5.2. b,  5. 


L2.c,5. 


4.3.b,  5. 


[5.  La 


5.La 


LLa,2. 
5.4.a,  6. 
7.3.a,  7. 


l5.4.a,  6. 


l.l.a,  2. 
5.4.a,  6. 
7.3.a,7. 
'5.4.a,  6. 


2.a,  5.3.b 


2. a,  2.3.a,  3.2.b,  5.2.a,  5.3.b, 
La,  6.2.a,  6.3.a,  7.2.b,  7.2.C, 

3. b,  7.4.a,  7.4.b,  7.5.a,  7.5.b 


2.a,  5.3.b  _ 


La,  6.3. a  _ 


2. a,  2.3.a,  3.2.b,  5.2.a,  5.3.b, 
La,  6.2.a,  6.3.a,  7.2.b,  7.2.c, 

3. b,  7.4.a,  7.4.b,  7.5.a,  7.5.b 


2.a,  5.3.b  _ 


La,  6.3.a  _ 


.Lb,  2.2.b,3.Lc,  4.Lb,5.Lc, 
.3.C,  5.4.b,  7.Lc,7.2.d,7.3.c 


4. a  _ 


.La,  5.3. a  _ 


2. a,  2.3.a,  3.2.b,  5.2.a,  5.3.b, 
La,  6.2.a,  6.3.a,  7.2.b,  7.2.c, 

3. b,  7.4.a,  7.4.b,  7.5.a,  7.5.b 


La,  6.3.a  _ 


2. a,  2.3.a,  3.2.b,  5.2.a,  5.3.b, 
La,  6.2.a,  6.3.a,  7.2.b,  7.2.c, 

3. b,  7.4.a,  7.4.b,  7.5.a,  7.5.b 
La,  6.3.a 


Design  Process _ 

Develop  OSSP _ _ 

Maintain  OSSP 


Design  Process 


Develop  OSSP 


Maintain  OSSP 


Gather  Internal  Data 


Plan  Training  Delive 


Identify  Training  Needs 


Project  Plannin 


Strategic  Plannin 


Perform  Trainin 


Develop  Training  Course 


Measure  Training  Qualit; 


Independent  Training  Evaluation 


[Evaluate  Trainin 


[Project  Plannin 


Analyze  Data 


Measure  Product 


Analyze  Data 


Project  Plannin 


Measure  Product _ 


Review  Project  (Event  Driven) 


Evaluate  Process 


Project  Review _ 


Develop  Design  Criteria 


Develop  Software  Arch  Design 


Develop  Software  Detail  Design 


Analyze  Data 


Measure  Product 


Analyze  Data 

Measure  Product 


AF-0038 

'aF-0191 

'aF-0192 


AF-0038 


AF-0191 


AF-0192 


AF-0098 


AF-0088 


AF-0089 


AF-0114 


AF-0075 


AF-0088 


AF-0124 


[AF-0125 


AF-0128 


[AF-0129 


AF-0018 


AF-0114 


lAF-0073 


AF-0114 


AF-0118 


AF-0073 


AF-0114 


I  AF-0118 


AF-0109 


AF-0070 


AF-0148 


AF-0153 


AF-0154 


AF-0155 


AF-0073 


[AF-0118 


AF-0073 


AF-0118 
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IC.Acl 


IC.Ac3 


IC.Ac3 


IC.Ac4 


IC.Ac4 


IC.Ac5 


PR.Ac2 


PR.Ac3 


QP.Acl 


QP.Acl 

QP.Ac2 


QP.Ac2 


QP.Ac2 


QP.Ac2 


QP.Ac3 


QP.Ac4 


QP.Ac4 


QP.Ac4 


QP.Ac4 


QP.Ac6 


SQ.Acl 


SQ.Ac2 


7.1.a 


5.4.a 


5.1.a,  5.2.a,5.3.b 


5.4.a 


SQ.Ac3 


SQ.Ac4 


SQ.Ac4 


DP.Acl 


DP.Ac3 


DP.Ac5 


DP.Ac5 


DP.AcS 


DP.Ac6 


DP.AcS 


5.1. a, 


5.1.b 


5.1.b 


5.1.b 


5.1.a, 


2.2.a 

2.2.a 


l.l.a, 


l.l.a, 

5.4.a, 

7.3.a, 


5.4.a, 


2.1. a. 


2.1. a. 


l.l.a. 


l.l.a, 

5.4.a, 

7.3.a, 


2.2.a 


5.4.a, 


5.1. a. 


l.l.a, 

5.4.a, 

7.3.a, 


5.4.a, 


2.2.a 


l.l.a, 

5.4.a, 

7.3.a, 


5.4.a, 


5.1. a. 


5.2.a, 


5.2.a,  5.3.b 


5.2.a,  5.3.b 


5.2.a,  5.3.b,  5.4.a,  6.2.a,  6.3.a 


2.2. a,  2.3.a,  3.2.b,  5.2.a,  5.3.b, 
6.1. a,  6.2.a,  6.3.a,  7.2.b,7.2.c, 

7.3. b,  7.4.a,  7.4.b,  7.5.a,  7.5.b 


7.2.a 


2.2.a,  5.4.a,  7.1.a _ 


2.2.a,  5.4.a,  7.1.a _ 


5.2.a,  5.3.b,  5.4.a,  6.2.a,  6.3.a 


2.2. a,  2.3.a,  3.2.b,  5.2.a,  5.3.b, 
6.1. a,  6.2. a,  6.3.a,  7.2.b,  7.2.c, 

7.3. b,  7.4.a,  7.4.b,  7.5.a,  7.5.b 


l.l.a. _ _ 


5.2.a,  5.3.b  _ 


2.2. a,  2.3.a,  3.2.b,  5.2.a,  5.3.b, 
6.1. a,  6.2.a,  6.3.a,  7.2.b,  7.2.c, 

7.3. b,  7.4.a,  7.4.b,  7.5.a,  7.5.b 


6.1. a,  6.3. a 


2.2. a,  2.3.a,  3.2.b,  5.2.a,  5.3.b, 
6.1. a,  6.2. a,  6.3.a,  7.2.b,  7.2.c, 

7.3. b,  7.4.a,  7.4.b,  7.5.a,  7.5.b 


6.1. a,  6.3. a  _ 


5.2.a,  5.3.b 


5.3.b 


l.l.a,  2.2.a,  2.3.a,  3.2.b,  5.2.a,  5.3.b, 
5.4.a,  6.1. a,  6.2. a,  6.3. a,  7.2.b,  7.2.c, 

7.3. a,  7.3.b,  7.4.a,  7.4.b,  7.5.a,  7.5.b 

5.4. a,  6.1. a,  6.3. a 


5.1.a  _ 


5.4.a,  l.l.a 


lEstablish  System  Requirements  AF-0166 


Communicate  Supplier  AF-0095 

Requirements 


Project  Planning  AF-0 1 14 


Determine  Key  Supplier  AF-0096 

Requirements 


AF-0114 


Review  Product  I AF-0 1 08 


Review  Product  AF-0 1 08 


I  Review  Product _ AF-0 108 


[Project  Planning _ AF-0114 


Set  Performance  Objectives  AF-0074 

Set  Performance  Objectives  AF-0074 


Measure  Process _ AF-0072 


Analyze  Data  AF-0073 


I  Communicate  Information _ |AF-0097 


Determine  Indicators  AF-0071 


Determine  Indicators _ AF-0071 

Measure  Process _ AF-0072 

Analyze  Data  AF-0073 


Set  Performance  Objectives  j  AF-0074 


[Communicate  Information  AF-0097 


Project  Planning _ AF-01 14 


Analyze  Data  AF-0073 


Measure  Product  _ AF-01 18 


Set  Performance  Objectives  AF-0074 


Analyze  Data  AF-0073 


Measure  Product  [AF-01 18 


AF-0114 


[Determine  Root  Cause  [AF-0043 


Determine  Root  Cause  AF-0043 


Analyze  Data  AF-0073 


[Measure  Product _ |AF-01 18 


[Maintain  OSSP _ AF-0 192 


Communicate  Information  AF-0097 


B-8 


TC.Acl 

3.1.a,  4.1.a 

Strategic  Planning 

AF-0075 

TC.Ac2 

2.2.a 

Identify  Technology  Change 

Areas 

AF-0178 

TC.Ac3 

5.4.a,  7.2.a 

Communicate  Information 

AF-0097 

TC.AcT 

5.1.a 

Maintain  OSSP 

AF-0192 

PC.Ac2 

l.l.a 

Set  Goals 

AF-0019 

PC.Ac3 

3.1. a,  4.1. a 

Strategic  Planning 

AF-0075 

PC.Ac4 

l.l.a,  5.2.a,  5.3.b,  5.4.a,  6.2.a,  6.3.a 

Measure  Process 

AF-0072 

PC.Ac4 

l.l.a,  2.2.a,  2.3.a,  3.2.b,  5.2.a,  5.3.b, 
5.4.a,  6.1. a,  6.2.a,  6.3.a,  7.2.b,  7.2.c, 
7.3.a,  7.3.b,  7.4.a,  7.4.b,  7.5.a,  7.5.b 

Analyze  Data 

AF-0073 

PC.Ac4 

l.l.a 

Set  Goals 

AF-0019 

PC.Ac4 

5.4.a,  7.2.a 

Communicate  Information 

AF-0097 

PC.Ac4 

3.2.a 

Develop  Action  Plan 

AF-0185 

PC.Ac4 

5.1.b 

Pilot  Process  Improvement 

AF-0186 

PC.Ac4 

2.2.a,5.1.a,  5.2.b,  5.3.b,  5.4.b 

Implement  Process 

AF-0187 

PC.Ac6 

3.2.a 

Develop  Action  Plan 

AF-0185 

PC.Ac? 

S.l.b 

Pilot  Process  Improvement 

AF-0186 

PC.AcS 

l.l.a,  5.2.a,  5.3.b,  5.4.a,  6.2.a,  6.3.a 

Measure  Process 

AF-0072 

l.l.a,  2.2.a,  2.3.a,  3.2.b,  5.2.a,  5.3.b, 
5.4.a,  6.1. a,  6.2.a,  6.3.a,  7.2.b,  7.2.c, 
7.3.a,  7.3.b,  7.4.a,  7.4.b,  7.5.a,  7.5.b 

Analyze  Data 

AF-0073 

PC.AcS 

2.2.a,5.1.a,5.2.b,  5.3.b,  5.4.b 

Implement  Process 

AF-0187 

PC.Ac  10 

5.4.a,  7.2.a 

Communicate  Information 

AF-0097 

PC.Mel 

l.l.a,  5.2.a,  5.3.b,  5.4.a,  6.2.a,  6.3.a 

Measure  Process 

AF-0072 

PC.Mel 

l.l.a,  2.2.a,  2.3.a,  3.2.b,  5.2.a,  5.3.b, 
5.4.a,  6.1. a,  6.2.a,  6.3.a,  7.2.b,  7.2.c, 
7.3.a,  7.3.b,  7.4.a,  7.4.b,  7.5.a,  7.5.b 

Analyze  Data 

AF-0073 
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Appendix  C  -  Quality  Air  Force  Relations  to  Capability  Maturity  Model  and  Integrated 

Requirements 

1.0  Purpose 

The  overall  purpose  of  this  document  is  to  reference  the  Quality  Air  Force  (QAF) 
criteria  to  the  Capability  Maturity  Model  for  Software  (CMM)  by  identifying  the 
integrated  requirements  that  relate  the  two  models. 

2.0  Overview 

This  document  maps  the  QAF  criteria  to  the  CMM  through  the  integrated 
requirements  that  correlate  back  to  each  model.  Only  the  QAF  criteria  areas  that  have  a 
relationship  to  CMM  practices  are  included.  The  document  is  organized  to  mirror  the 
categories,  areas  to  address,  and  items  in  the  QAF  criteria.  The  related  area  of  the  CMM 
is  provided  along  with  the  name  and  ID  of  the  integrated  requirement  that  correlates  to 
that  QAF  area  and  the  identified  CMM  practices. 
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3.0  Guide  to  Codes 


3. 1  Capability  Maturity  Model  Codes. 

3.1.1  Key  Process  Areas  (KPAs): 

RM  Requirements  Management 

PP  Software  Project  Planning 

PT  Software  Project  Tracking  &  Oversight 

SM  Software  Subcontract  Management 

QA  Software  Quality  Assurance 

CM  Software  Configuration  Management 

PF  Organization  Process  Focus 

PD  Organization  Process  Definition 

TP  Training  Program 

IM  Integrated  Software  Management 

PE  Software  Product  Engineering 

IC  InterGroup  Coordination 

PR  Peer  Reviews 

QP  Quantitative  Process  Management 

SQ  Software  Quality  Management 

DP  Defect  Prevention 

TC  Technology  Change  Management 

PC  Process  Change  Management 

3.1.2  Other  Common  Features  (OCFs): 

Co  Commitment  to  Perform 

Ab  Ability  to  Perform 

Me  Measurement  and  Analysis 

Ve  Verifying  Implementation 
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3.2  Quality  Air  Force  Criteria  Codes 


1.0  Leadership 

1 . 1  Senior  Executive  Leadership 

1.2  Leadership  System  and  Organization 

1.3  Public  Responsibility  and  Citizenship 
2.0  Information  and  Analysis 

2. 1  Management  of  Information  and  Data 

2.2  Comparisons  and  Benchmarking 

2.3  Analysis  and  Use  of  Organization-Level  Data 
3.0  Strategic  Planning 

3.1  Strategy  Development 

3.2  Strategic  Deployment 

4.0  Human  Resource  Development  and  Management 

4. 1  Human  Resource  Planning  and  Evaluation 

4.2  High  Performance  Work  Systems 

4.3  Member  Education,  Training,  and  Development 

4.4  Well  Being  and  Satisfaction 
5.0  Process  Management 

5. 1  Design  and  Introduction  of  Products  and  Services 

5.2  Key  Process  Management:  Product  and  Service  Production 

and  Delivery 

5.3  Process  Management:  Support  Services 

5.4  Supplier  Performance  Management 
6.0  Performance  Results 

6.1  Product  and  Service  Quality 

6.2  Operational  Performance  and  Financial  Results 

6.3  Supplier  Performance  Results 
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7.0  Customer  Focus  and  Customer  Satisfaction 

7.1  Customer  Knowledge 

7.2  Customer  Management 

7.3  Customer  Satisfaction  Determination 

7.4  Customer  Satisfaction  Results 

7.5  Customer  Satisfaction  Comparison 
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4.0  Reference 
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^ni  to 


4.3.a 


4.3.a 


4.3.a 


4.3.b 


TP.Ve3 _ 


TP.Me2 


|TP.Ve2  _ 


TP.VeS 


PF.Ac6,  TP.Acl,  TP.Ac2 


iTP.Acl  _ 


TP.Ac3 


TP.Ac4 


TP.Me2  _ 


rTP.Ve2  _ 


PE.Ac3  _ 


PD. Ac  1 ,  PD. Ac2  _ 


PP.Ac2,  PP.Ac3,  PP.Ac5,  PP.Ac6, 
PP.Ac7,  PP.Acl4,  PT.Acl,  PT.Ac2, 
QA.Acl,  QA.Ac3,  CM.Acl, 

TP.Acl,  IM.Ac3,  IM.Ac4,  IM.Ac5, 
IC.Ac3,  IC.Ac4,  QP.Acl,  SQ.Acl, 
DP.Acl  _ 


PE.Ac3  _ 


PE.Ac3 


PE.Ac3  _ 


PC.Ac4,  PC.AcS _ 


PF.Co2,  PF.Co3,  PF.Ac3,  PD.Acl, 
PD.Ac2  _ 


PF.Co2,  PF.Co3,  PF.Ac3,  PD.Acl, 
PD.Ac2,  DP.Ac6,  TC.Ac7 _ 


SM.Ac4,  QA.Ac2,  QA.Ac5, 
0A.Ac7,  IC.Ac5,  PR.Ac2,  PR.Ac3 
iPF.AcS,  PC.Ac4,  PC.Ac7 _ 


SM.Acl3,  IM.Acll,Ve _ 


DP.Ac3,  DP.Ac5 _ 

'qP.Ac2,  QP.Ac4,  PC.AcS,  PC.Mel, 

Me  _ 

’  PT.Acl  1,  PF.Ac4,  IM.Ac4,  IM.AcS, 
PE.Ac9,  PE.Mel,  QP.Ac2,  QP.Ac4, 
SQ.Ac2,  SQ.Ac4,  DP.AcS,  PC.AcS, 
PC.Mel,  Me  _ 


PP.Ac2,  PP.Ac3,  PP.Ac5,  PP.Ac6, 
PP.Ac7,  PP.Acl4,  PT.Acl,  PT.Ac2, 
QA.Acl,  QA.Ac3,  CM.Acl, 
TP.Acl,  IM.Ac3,  IM.Ac4,  IM.AcS, 
IC.Ac3,  IC.Ac4,  QP.Acl,  SQ.Acl, 
DP.Acl  _ 


PT.AcS,  PT.Ac6,  PT.Ac7,  PT.AcS, 
PT.Ac9,  PT.AclO,  Ve 


Evaluate  Trainin 


Measure  Training  Qualit 


Independent  Training  Evaluation 


Evaluate  Trainin 


Plan  Training  Delive 


Identify  Training  Needs _ 


Perform  Trainin 


Develop  Training  Course _ 


Measure  Training  Qualit 


Independent  Training  Evaluation 


Develop  Design  Criteria _ 


Design  Process 


I  Project  Planning 


AF-0018 


AF-012S 


AF-0129 


AF-OOIS 


AF-OOSS 


AF-00S9 


AF-0124 


AF-Oi25 


AF-012S 


AF-0129 


AF-0153 


AF-003S 


AF-0114 


I  Develop  Design  Criteria _ 


Develop  Software  Architecture 
Design 


Develop  Software  Detail  Design 


Implement  Process 


Develop  OSSP 


Maintain  OSSP 


Review  Product 


Evaluate  Process 


Determine  Root  Cause 
Measure  Process 

Analyze  Data 


iProject  Planning 


AF-0153 


AF-0154 


AF-0155 


AF-01S7 


AF-0191 


AF-0192 


AF-OIOS 

'aF-01S6 


lAF-0070 


AF-0043 

'aF-0072 

'aF-0073 


AF-01 14 


Take  Corrective  Actions 


I  AF-01 16 
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SM.AcB,  IM.Acll,  Ve 

Evaluate  Process 

AF-0070 

SM.Acl 

Determine  Partnering  Activities 

AF-00S5 

PT.Ac4,  SM.Ac6 

Change  Supplier  Commitment 

AF-OIB 

SM.Acl 

Plan  Supplier  Work 

AF-0119 

PC.Ac4,  PC.AcS 

Implement  Process 

AF-01S7 

6.1.a 

PT.Acl  L  PF.Ac4,  IM.Ac4,  IM.AcS, 
PE.Ac9,  PE.Mel,  QP.Ac2,  QP.Ac4, 
SQ.Ac2,  SQ.Ac4,  DP.AcS,  PC.AcS, 
PC.Mel,Me 

Analyze  Data 

AF-0073 

6.  La 

PP.AclS,  PD.Ac5 

Gather  Internal  Data 

AF-0098 

6.  La 

PT.Acl  L  PF.Ac4,  IM.Ac4,  IM.AcS, 
PE.Ac9,  PE.MeL  SQ.Ac2,  SQ.Ac4, 
DP.AcS 

Measure  Product 

AF-0118 

6.2.a 

QP.Ac2,  QP.Ac4,  PC.AcS,  PC.Mel, 
Me 

Measure  Process 

AF-0072 

6.2.a 

PT.Acl  1,  PF.Ac4,  IM.Ac4,  IM.AcS, 
PE.Ac9,  PE.Mel,  QP.Ac2,  QP.Ac4, 
SQ.Ac2,  SQ.Ac4,  DP.AcS,  PC.AcS, 
PC.Mel,  Me 

Analyze  Data 

AF-0073 

6.2.a 

PP.AclS,  PD.AcS 

Gather  Internal  Data 

AF-0098 

6.3.a 

QP.Ac2,  QP.Ac4,  PC.AcS,  PC.Mel, 
Me 

Measure  Process 

AF-0072 

6.3.a 

PT.Acl  1,  PF.Ac4,  IM.Ac4,  IM.AcS, 
PE.Ac9,  PE.Mel,  QP.Ac2,  QP.Ac4, 
SQ.Ac2,  SQ.Ac4,  DP.AcS,  PC.AcS, 
PC.MeLMe 

Analyze  Data 

AF-0073 

6.3.a 

PT.Acl  1,  PF.Ac4,  IM.Ac4,  IM.AcS, 
PE.Ac9,  PE.MeL  SQ.Ac2,  SQ.Ac4, 
DP.AcS 

Measure  Product 

AF-0118 

7.La 

OP.Ac3,  OP.Ac4 

Determine  Indicators 

AF-0071 

7.La 

SM.Ac2 

Select  Group 

AF-0100 

7.La 

IC.Acl 

Establish  System  Requirements 

AF-0166 

Evaluate  Process 

AF-0070 

7.2.a 

QA.Ac2,  QA.Ac6,  QA.AcS, 
CM.Ac2,  CM.Ac9,  PF.Ac7, 

QP.Ac2,  QP.Ac6,  DP.AcS,  TC.Ac3, 
PC.Ac4,  PC. Ac  10 

Communicate  Information 

AF-0097 

7.2.b 

PT.Acl  1,  PF.Ac4,  IM.Ac4,  IM.AcS, 
PE.Ac9,  PE.MeL  QP.Ac2,  QP.Ac4, 
SQ.Ac2,  SQ.Ac4,  DP.AcS,  PC.AcS, 
PC.MeLMe 

Analyze  Data 

AF-0073 

7.2.C 

PT.Acl  1,  PF.Ac4,  IM.Ac4,  IM.AcS, 
PE.Ac9,  PE.Mel,  QP.Ac2,  QP.Ac4, 
SQ.Ac2,  SQ.Ac4,  DP.AcS,  PC.AcS, 
PC.MeLMe 

Analyze  Data 

AF-0073 

7.2.d 

SM.AcB,  IM. Ac ll,Ve 

Evaluate  Process 

AF-0070 
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7.3.a 

PT.Acl  1,  PF.Ac4,  IM.Ac4,  IM.Ac5, 
PE.Ac9,  PE.Mel,  QP.Ac2,  QP.Ac4, 
SQ.Ac2,  SQ.Ac4,  DP.Ac5,  PC.AcS, 
PC.Mel,  Me 

Analyze  Data 

AF-0073 

7.3.b 

PT.Acl  1,  PF.Ac4,  IM.Ac4,  IM.AcS, 
PE.Ac9,  PE.Mel,  QP.Ac2,  QP.Ac4, 
SQ.Ac2,  SQ.Ac4,  DP.Ac5,  PC.AcS, 
PC.Mel,  Me 

Analyze  Data 

AF-0073 

7.3.C 

SM.Acl3,IM.Acll,Ve 

Evaluate  Process 

AF-0070 

7.4.a 

PT.Acl  1,  PF.Ac4,  IM.Ac4,  IM.Ac5, 
PE.Ac9,  PE.Mel,  QP.Ac2,  QP.Ac4, 
SQ.Ac2,  SQ.Ac4,  DP.AcS,  PC.AcS, 
PC.Mel,  Me 

Analyze  Data 

AF-0073 

7.4.b 

PT.Acl  1,  PF.Ac4,  IM.Ac4,  IM.Ac5, 
PE.Ac9,  PE.Mel,  QP.Ac2,  QP.Ac4, 
SQ.Ac2,  SQ.Ac4,  DP.Ac5,  PC.AcS, 
PC.Mel,Me 

Analyze  Data 

AF-0073 

7.5.a 

PT.Acl  1,  PF.Ac4,  IM.Ac4,  IM.Ac5, 
PE.Ac9,  PE.Mel,  QP.Ac2,  QP.Ac4, 
SQ.Ac2,  SQ.Ac4,  DP.AcS,  PC.AcS, 
PC.Mel,  Me 

Analyze  Data 

AF-0073 

7.5.b 

PT.Acl  1,  PF.Ac4,  IM.Ac4,  IM.AcS, 
PE.Ac9,  PE.Mel,  QP.Ac2,  QP.Ac4, 
SQ.Ac2,  SQ.Ac4,  DP.AcS,  PC.AcS, 
PC.Mel,Me 

Analyze  Data 

AF-0073 
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Appendix  D  -  Capability  Maturity  Model  Map  to  Integrated  Requirements 


1.0  Purpose 

The  overall  purpose  of  this  document  is  to  reference  the  Capability  Maturity  Model 
for  Software  (CMM)  to  the  integrated  requirements. 

2.0  Overview 


This  document  maps  the  CMM  to  the  integrated  requirements.  All  CMM  practices 
are  included.  The  document  is  organized  to  mirror  the  maturity  levels  and  key  process 
areas  of  the  CMM. 

3.0  Guide  to  Codes 

3.1  Key  Process  Areas  (KPAs): 

RM  Requirements  Management 

PP  Software  Project  Planning 

PT  Software  Project  Tracking  &  Oversight 

SM  Software  Subcontract  Management 

QA  Software  Quality  Assurance 

CM  Software  Configuration  Management 

PF  Organization  Process  Focus 

PD  Organization  Process  Definition 

TP  Training  Program 

DM  Integrated  Software  Management 

PE  Software  Product  Engineering 

IC  InterGroup  Coordination 

PR  Peer  Reviews 

QP  Quantitative  Process  Management 

SQ  Software  Quality  Management 

DP  Defect  Prevention 

TC  Technology  Change  Management 

PC  Process  Change  Management 
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3.2  Other  Common  Features  (OCFs): 


Co  Commitment  to  Perform 

Ab  Ability  to  Perform 

Me  Measurement  and  Analysis 

Ve  Verifying  Implementation 
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RM.Abl 


RM.Ab2 


RM.Acl 


RM.Ac2 


RM.Ac3 


PP.Acl 


PP.Ac2 


PP.Ac3 


PP.Ac4 


PP.Ac6 


PP.Ac7 


PP.Ac8 


PP.Ac9 


PRAclO 


PP.Acll 


PP.Acl2 


Name 


Other  Common  Features 


Adequate  Resources 


Follows  Polic 


Follows  Procedure 


Determine  Status 


Measure  Process 


Software  Project  Plannin 


Develop  Project  Proposal 


Make  Commitment 


Project  Review 


Develop  Software  LifeCycle  Descriptions 


Maintain  Software  LifeCycle  Descriptions 


[Identify  Software  Work  Products 


[Estimate  Size _ _ 


Estimate  Effort _ 


Estimate  Cost 


[Estimate  Critical  Computer  Resources 


Derive  Schedule 


AF-0055 


AF-0056 


AF-0057 


AF-0054 


AF-0058 


AF-0059 


AF-0072 


Analyze  Data 

AF-0073 

Measure  Activity 

AF-01 10 

Evaluate  Process 

AF-0070 

Event  Driven  Review 

AF-0109 

Take  Corrective  Actions 

AF-01 16 

Project  Review 

AF-0148 

Requirements  Management 

Allocate  Requirements 

AF-0060 

Allocate  Requirements 

AF-0060 

Negotiate  Commitments 

AF-01 11 

Review  Allocated  Requirements 

AF-0149 

Correct  Allocated  Requirements 

AF-0150 

Develop  Software  Requirements 

AF-01 12 

Assess  Requirements  Change 

AF-0061 

Make  Commitment 

AF-0115 

Review  Allocated  Requirements 

AF-0149 

AF-0063 


AF-0114 


AF-0114 


AF-0115 


AF-0148 


AF-01 14 


AF-0193 


AF-01 96 


AF-0114 


AF-0014 


AF-0114 


AF-01 32 


AF-01 33 


AF-01 34 


AF-01 35 


AF-01 36 


AF-01 37 
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PP.Acl3 


PP.Acl4 


PP.Acl5 


PT.Acl 


PT.Ac2 


PT.Ac3 


PT.Ac4 


PT.Ac5 


PT.Acl2 


PT.Acl3 


Risk  Identification 


Risk  Analysis 


Risk  Prioritization 


Gather  Internal  Data 


Estimate  Size 


Estimate  Effort 


Estimate  Cost 


Estimate  Critical  Computer  Resources 


Derive  Schedule 


Risk  Identification 


Software  Proiect  Tracking  &  Oversight 


SM.Ac4 


SM.Ac5 


SM.Ac6 


Make  Commitment 


Change  Supplier  Commitment 


Take  Corrective  Actions  _ 


Manage  Size 


Take  Corrective  Actions 


Manage  Effort 


Manage  Cost 


Take  Corrective  Actions 


Manage  Critical  Computer  Resources 


Take  Corrective  Actions 


Manage  Schedule 


Take  Corrective  Actions 


Track  Technical  Activities  _ 


Take  Corrective  Actions 


Manage  Risks  _ 


Analyze  Data  _ 


Measure  Product  _ 


Measure  Activif 


Project  Review 


Project  Review  _ 


Software  Subcontract  Management 


Determine  Partnering  Activities 


Determine  Kev  Supplier  Requirements 


Plan  Supplier  Work 


Process  Assessment 


Select  Grou 


Make  Contractual  Agreement 


Communicate  Supplier  Requirements 


Review  Product 


Activity  Review  _ 


Change  Supplier  Commitment 


AF-0138 


AF-0139 


AF-0140 


AF-0114 


AF-0098 


AF-0133 


AF-0134 


AF-0135 


AF-0136 


AF-0137 


AF-0138 


AF-0114 


AF-0114 


AF-0115 


AF-0113 


AF-0116 


AF-0141 


AF-0116 


AF-0142 


AF-0143 


AF-0116 


AF-0144 


AF-0116 


AF-0169 


AF-0116 


AF-0117 


AF-0116 


AF-0147 


AF-0073 


AF-0118 


AF-0110 


AF-0148 


AF-0148 


lAF-0085 


IaF-0096 


AF-0119 


AF-0080 


AF-0100 


AF-0062 


AF-0095 


AF-0108 


AF-0120 


AF-0113 
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SM.Ac7 


SM.Ac8 


SM.Ac9 


SM.AC10 


SM.Acll 


SM.Acl2 


SM.Acl3 


A.Acl 


A.Ac2 


A.Ac6 


A.Ac7 


CM.Acl 


CM.Ac2 


CM.Ac5 


CM.Ac6 


CM.Ac7 


CM.Ac8 


CM.Ac9 


CM-AclO 


CM.Ve3 


Project  Review 

AF-0 148 

Activity  Review 

AF-0 120 

Project  Review 

AF-0148 

Activity  Review 

AF-0 120 

Activity  Review 

AF-0120 

Perform  Supplier  Acceptance  Tests 

AF-0064 

Evaluate  Process 

AF-0070 

Software  Quality  Assurance 

AF-0114 

Activity  Review 

AF-0120 

Communicate  Information 

AF-0097 

Handle  Deviations 

AF-0065 

Review  Product 

AF-0 108 

AF-0114 

Develop  PDSP 

AF-0 130 

Revise  PDSP 

AF-0131 

Activity  Review 

AF-0120 

Review  Product 

AF-0 108 

Communicate  Information 

AF-0097 

Handle  Deviations 

AF-0065 

Review  Product 

AF-0 108 

Communicate  Information 

AF-0097 

Software  Configuration  Management 


AF-0114 


Establish  CM  Library  System  AF-0066 


Identify  Software  Configuration  Items  AF-0067 


Identify  Software  Work  Products  AF-0132 


Handle  Change  Requests  AF-0068 


Change  Baseline  AF-0069 


Communicate  Information  AF-0097 


Record  SCI  Status  AF-0190 


Audit  B  aseline  _ AF-0121 


Release  Product  |AF-0189 


Release  Product  AF-0189 


Establish  CM  Library  System  AF-0066 


Identify  Software  Configuration  Items  AF-0067 


Identify  Software  Work  Products  AF-0132 


Handle  Change  Requests  AF-0068 


Change  Baseline  _ AF-0069 


Release  Product  _ AF-0189 


Record  SCI  Status  AF-0 190 


Record  SCI  Status  _ AF-0190 


Communicate  Information  AF-0097 


Audit  Baseline  AF-0121 


Audit  B  aseline  AF-0 1 2 1 
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PF.Ac2 


PF.Ac3 


PF.Ac5 


PF.Ac6 


PF.Ac7 


Organization  Process  Focus 


Develop  Software  LifeCycle  Descriptions 


Maintain  Software  LifeCycle  Descriptions 


Develop  Tailoring  Guidelines 


Maintain  Tailoring  Guidelines 


Develop  Software  LifeCycle  Descriptions 


Maintain  Software  LifeCycle  Descriptions 


Develop  Tailoring  Guidelines 


Maintain  Tailoring  Guidelines 


Process  Assessment 


Develop  Action  Plan 


\mmm 


Develop  PDSP 


Revise  PDSP  _ 


Analyze  Data 


Estimate  Size 


Estimate  Effort 


Estimate  Cost 


Estimate  Critical  Computer  Resources 


Derive  Schedule 


Maintain  Software  Process  Database 


Measure  Product  _ 


Pilot  Process  Improvement 


imsmssmsm 


Communicate  Information 


Organization  Process  Definition 


Maintain  Software  Process  Libra 


Training  Program 


Identify  Training  Needs 


AF-0193 


AF-0196 


AF-0194 


AF-0195 


AF-0193 


AF-0196 


AF-0194 


AF-0195 


AF-0080 


AF-0185 


AF-0075 


AF-0130 


AF-013I 


AF-0073 


]AF-0133 


lAF-0134 


AF-0135 


AF-0136 


AF-0137 


AF-0111 


AF-0118 


AF-0186 


AF-0088 


AF-0097 


Maintain  OSSP 

AF-0192 

Develop  OSSP 

AF-0191 

Design  Process 

AF-0038 

Maintain  OSSP 

AF-0192 

Develop  OSSP 

AF-0191 

Design  Process 

AF-0038 

Develop  Software  LifeCycle  Descriptions 

AF-0193 

Maintain  Software  LifeCycle  Descriptions 

AF-0196 

Develop  Tailoring  Guidelines 

AF-0194 

Maintain  Tailoring  Guidelines 

AF-0195 

Gather  Internal  Data 

AF-0098 

Maintain  Software  Process  Database 

AF-0111 

Plan  Training  Deliver 


AF-0088 


AF-0089 


AF-0114 


AF-0075 


AF-0088 
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TP.Ac3  I  Perform  Training _ _ _ |AF-0124 


TP.Ac4  Develop  Training  Course _  AF-0125 


Maintain  Training  Course  AF-0126 


TP.Ac5  Conduct  Training  Waiver  Procedure _ AF-0127 


TP.Ac6  [Maintain  Training  Records _ AF-0122 


rrRMe2 _ Measure  Training  Quality _ AF-0128 


TP.Vel  [independent  Training  Evaluation _ AF-0129 


TP.Ve3  Evaluate  Training _ AF-0018 


Integrated  Software  Management 


IM.Acl  [Develop  PDSP _ AF-0130 


IM.Ac2  Revise  PDSP _ AF-0131 


IM. Ac3  Project  Planning _ AF-0114 


IM.Ac4  Analyze  Data _ AF-0073 


Measure  Product  _ AF-0118 


AF-0114 


Identify  Software  Work  Products _ AF-0132 


Estimate  Size  _ AF-0133 


Estimate  Effort  _ AF-0134 


Estimate  Cost  _ AF-0135 


Estimate  Critical  Computer  Resources _ AF-0136 


Derive  Schedule  _ AF-0137 


Risk  Identification  _ AF-0138 


Risk  Analysis  _ AF-0139 


Risk  Prioritization  _ AF-0140 


Manage  Critical  Paths  _ AF-0145 


IM.Ac5  Analyze  Data _ AF-0073 


AF-0114 


Measure  Product  _ AF-0118 


Estimate  Size  _ AF-0133 


Estimate  Effort  _ AF-0134 


Estimate  Cost  _ AF-0135 


Estimate  Critical  Computer  Resources _ AF-0136 


Derive  Schedule  _ AF-0137 


Risk  Identification  _ AF-0138 


Risk  Analysis  _ AF-0139 


Risk  Prioritization  _ AF-0140 


Manage  Critical  Paths  _ AF-0145 


IM.Ac6  [Estimate  Size _ AF-0133 


Manage  Size  _ AF-0141 


IM.Ac7  [Estimate  Effort _ AF-0134 


Estimate  Cost  _ AF-0135 


Manage  Effort  _ AF-0142 


Manage  Cost _ AF-0143 


lM.Ac8 _ Estimate  Critical  Computer  Resources _ AF-0136 


Manage  Critical  Computer  Resources _ AF-0144 
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IM.Ac9 


PE.Acl 


PE.Ac2 


PE.Ac4 


PE.Ac5 


PKAclO 


PE.Mel 


PE.Mel 


IC.Acl 


IC.Ac2 


IC.Ac3 


IC.Ac4 


Derive  Schedule 

AF-0137 

Manage  Critical  Paths 

AF-0145 

Manage  Schedule 

AF-0169 

Risk  Identification 

AF-0138 

Risk  Analysis 

AF-0139 

Risk  Prioritization 

AF-0140 

Develop  Software  Risk  Management  Plan 

AF-0146 

Manage  Risks 

AF-0147 

Event  Driven  Review 

AF-0109 

Evaluate  Process 

AF-0070 

Project  Review 

AF-0148 

Software  Product  Engineerin 


Develop  PDSP 


Review  Allocated  Requirements 


Correct  Allocated  Requirements 


Requirements  Analysis 


Develop  Software  Requirements  Document 


Develop  Design  Criteria 


Develop  Software  Architecture  Design 


Develop  Software  Detail  Design 


Develop  Software  Code 


Plan  Unit  Tests 


Perform  Unit  Tests 


Plan  Integration  Tests 


Perform  Integration  Tests  _ 


Plan  System  Tests  _ 


Perform  System  Tests 


Develop  Software  Documentation 


Maintain  Software  Documentation 


Analyze  Data  _ 


Measure  Product 


Maintain  Consistenc 


Analyze  Data  _ 


Measure  Product  _ 


InterGroup  Coordination 


Establish  System  Requirements 


Track  Technical  Activities 


Coordinate  Technical  Activities  _ 


Resolve  InterGroup  Issues 


Communicate  Supplier  Requirements 


Protect  Plannin 


Determine  Key  Supplier  Requirements 


Project  Plannin 


Manage  Critical  Paths  _ 


Manage  Schedule 


AF-0130 


AF-0149 


IaF-0150 


lAF-0151 


AF-0152 


AF-0153 


AF-0154 


AF-0155 


AF-0156 


AF-0157 


AF-0158 


AF-0159 


AF-0160 


AF-0161 


AF-0162 


AF-0163 


IaF-0164 


AF-0073 


AF-0118 


AF-0165 


AF-0073 


AF-0118 


lAF-0166 


AF-0117 


AF-0167 


AF-0168 


IaF-0095 


AF-0114 


lAF-0096 


AF-0114 


lAF-0145 


AF-0169 
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IC.Ac5 


IC.Ac6 


IC.Ac7 


PR.Acl 


PR.Ac2 


PR.Ac3 


P.Ac5 


P.Ac6 


P.Ac7 


DP.Acl 


DP.Ac2 


DP.Ac6 


Review  Product 


Resolve  InterGroup  Issues 


Activity  Review 


Peer  Reviews 


Plan  Peer  Review 


Review  Product 


Review  Product 


uantitative  Process  Management 


Develop  Measurement  Analysis  Strate 


Software  Oualitv  Management 


Analyze  Data 


Measure  Product 


Manage  Qualit 


Allocate  Quality  Goals _ 


Defect  Prevention 


I  Conduct  Task  Preparation  Meetin 


AF-0108 


AF-0168 


AF-0120 


AF-0170 


AF-0108 


AF-0108 


AF-0114 


Set  Performance  Objectives 

AF-0074 

Set  Performance  Objectives 

AF-0074 

Measure  Process 

AF-0072 

Analyze  Data 

AF-0073 

Analyze  PDSP 

AF-0172 

Communicate  Information 

AF-0097 

Maintain  Process  Capability  Baseline 

AF-0173 

Determine  Indicators 

AF-0071 

Determine  Indicators 

AF-0071 

Set  Performance  Objectives 

AF-0074 

Measure  Process 

AF-0072 

Analyze  Data 

AF-0073 

Analyze  PDSP 

AF-0172 

Communicate  Information 

AF-0097 

Maintain  Process  Capability  Baseline 

AF-0173 

Analyze  Data 

AF-0073 

Measure  Product 

AF-0118 

Set  Performance  Objectives 

AF-0074 

AF-0118 


AF-0174 


AF-0175 


DP.Ac3 

Determine  Root  Cause 

AF-0043 

DP.Ac4 

Coordinate  Prevention  Action 

AF-0177 

DP.Ac5 

Analyze  Data 

AF-0073 

Measure  Product 

AF-0118 

Determine  Root  Cause 

AF-0043 

Coordinate  Prevention  Action 

AF-0177 

Maintain  OSSP 

AF-0192 
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DP.Ac7  [Revise  PDSP _ AF-0131 


DP.Ac8  I  Communicate  Information _ AF-0097 


Technology  Change  Management 


TC.Acl  Strategic  Planning _ AF-0075 


TC. Ac2  Identify  Technology  Change  Areas _ AF-0178 


TC.Ac3  _ Communicate  Information _ AF-(X)97 


frC.Ac4  Analyze  OSSP _ AF-0179 


|TC.Ac5  Select  Technology _ AF-0180 


ry _ AF-0181 


TC.Ac6  _ Conduct  Technology  Pilot _ AF-0182 


TC.Ac7  _ Analyze  OSSP _ AF-0179 


Maintain  OSSP  _ AF-0192 


TC.Ac8  Revise  PDSP _ AF-0131 


Process  Change  Management 


PC.Acl  Maintain  Improvement  Program _ AF-0040 


PC.Ac2  Set  Goals _ AF-0019 


Coordinate  Process  Improvement  Activities  AF-0183 


Review  Process  Improvement  Proposal _ AF-0184 


PC.Ac3  Strategic  Planning _ AF-0075 


PC.Ac4  Set  Goals _ AF-0019 


Coordinate  Process  Improvement  Activities  AF-0183 


Review  Process  Improvement  Proposal _ AF-0184 


Develop  Action  Plan  _ AF-0185 


Communicate  Information _ AF-0097 


Pilot  Process  Improvement  _ AF-0186 


Measure  Process  _ AF-0072 


Analyze  Data _ AF-0073 


Implement  Process  _ AF-0187 


Maintain  SPI  Activity  Records _ AF-0188 


PC.Ac5  Review  Process  Improvement  Proposal _ AF-0184 


PC.Ac6  [Develop  Action  Plan _ AF-0185 


PC.Ac7  [pilot  Process  Improvement _ AF-0186 


PC.Ac8  Measure  Process _ AF-0072 


Analyze  Data _ AF-0073 


Implement  Process  _ AF-0187 


PC.Ac9  [Maintain  SPI  Activity  Records _ AF-0188 


PC.AclO  [Communicate  Information _ AF-0097 


PC.Me  [Measure  Process _ AF-0072 


PC.Me  [Analyze  Data _ AF-0073 


D-10 


Appendix  E  -  Quality  Air  Force  Criteria  Map  to  Integrated  Requirements 


1.0  Purpose 

The  overall  purpose  of  this  document  is  to  reference  the  Quality  Air  Force  (QAF) 
criteria  to  the  integrated  requirements. 

2.0  Overview 

This  document  maps  the  QAF  to  the  integrated  requirements.  All  QAF  areas  and 
items  are  included.  The  document  is  organized  to  mirror  the  categories,  areas  to  address, 
and  items  in  the  QAF  criteria. 

3.0  Guide  to  Codes 


1.0  Leadership 

1 . 1  Senior  Executive  Leadership 

1.2  Leadership  System  and  Organization 

1.3  Public  Responsibility  and  Citizenship 

2.0  Information  and  Analysis 

2. 1  Management  of  Information  and  Data 

2.2  Comparisons  and  Benchmarking 

2.3  Analysis  and  Use  of  Organization-Level  Data 

3.0  Strategic  Planning 

3 . 1  Strategy  Development 

3.2  Strategic  Deployment 

4.0  Human  Resource  Development  and  Management 

4. 1  Human  Resource  Planning  and  Evaluation 

4.2  High  Performance  Work  Systems 

4.3  Member  Education,  Training,  and  Development 

4.4  Well  Being  and  Satisfaction 
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5.0  Process  Management 

5.1  Design  and  Introduction  of  Products  and  Services 

5.2  Key  Process  Management:  Product  and  Service  Production 

and  Delivery 

5.3  Process  Management:  Support  Services 

5.4  Supplier  Performance  Management 

6.0  Performance  Results 

6. 1  Product  and  Service  Quality 

6.2  Operational  Performance  and  Financial  Results 

6.3  Supplier  Performance  Results 

7.0  Customer  Focus  and  Customer  Satisfaction 

7.1  Customer  Knowledge 

7.2  Customer  Management 

7.3  Customer  Satisfaction  Determination 

7.4  Customer  Satisfaction  Results 

7.5  Customer  Satisfaction  Comparison 
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Area  I  Name  _  I  ID 


Leadershi 


l.l,a  I  Develop  Organizational  Values _ AF-0001 


Set  Directions  AF-0002 


Set  Expectations _ AF-0003 


Build  Organizational  Capabilities  AF-0011 


Set  Goals  _ AF-0019 


Recognize  Member  _ AF-0027 


Measure  Process  |AF-0072 


Analyze  Data  _ AF-0073 


Reinforce  Organizational  Values _ AF-0078 


Process  Assessment  _ AF-0080 


Review  Organizational  Structure  _ AF-0005 


Improve  Leadership  System  _ AF-0012 


Improve  Organization  Structure _ AF-0013 


Evaluate  Process  _ AF-0070 


Communicate  Leadership  Information _ AF-0079 


Review  Organizational  Performance _ AF-0004 


Process  Assessment  _ AF-0080 


Event  Driven  Review  _ AF-0109 


Project  Review  _ AF-0148 


Set  Citizenship  Goals _ AF-0081 


Assess  Community  Impact _ AF-0082 


Improve  Community  Involvement _ AF-0021 


Plan  Community  Involvement _ AF-0083 


Information  &  Analysis 


2.1.a  _ Determine  Customer  Data  Requirements _ AF-0006 


Determine  Indicators  _ AF-007 1 


Evaluate  Process  _ AF-0070 


2.2.a  Determine  Benchmarking  Requirements _ AF-0007 


Set  Benchmarking  Priorities _ AF-0008 


Determine  Benchmarking  Data  Criteria _ AF-0009 


Develop  Breakthrough  Approach _ AF-0022 


Determine  Indicators  _ AF-007 1 


Analyze  Data _ _ _ AF-0073 


Set  Performance  Objectives _ AF-0074 


Gather  External  Data _ AF-0084 


Identify  Technology  Change  Areas _ AF-0178 


Implement  Process  _ AF-0187 


Evaluate  Process _ AF-0070 


2.3.a  _ Aggregate  Data _ AF-0010 


Analyze  Data _ AF-0073 


Gather  Internal  Data  _ AF-0098 
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strategic  Plannin 


4.1.a 


4.1.b 


AF-0075 

Set  Objectives 

AF-0014 

Determine  Key  Performance  Drivers 

AF-0015 

Determine  Partnering  Activities 

AF-0085 

Evaluate  Process 

AF-0070 

Align  Plans 

AF-0086 

Develop  Action  Plan 

AF-0185 

Project  Key  Indicator  Data 

AF-0016 

Determine  Benefits 

AF-0017 

Analyze  Data 

AF-0073 

Human  Resource  Development  and 
Management 


Assess  Member  Well-Bein 


Assess  Member  Development 


Evaluate  Process 


Align  Plans  _ 


Assess  Workforce  Satisfaction 


Assess  Workforce  Motivation 


Recognize  Member 


Compensate  Member 


Evaluate  Member 


Evaluate  Trainin 


Assess  Member  Development 


Evaluate  Job  Design 


Reinforce  Trainin 


Plan  Training  Delive 


Identify  Training  Needs 


Perform  Trainin 


Develop  Training  Course 


Measure  Training  Quality _ 


Independent  Training  Evaluation 


Develop  Design  Criteria 


Review  Work  Environment 


Improve  Work  Environment 


AF-0075 


lAF-0024 


AF-0070 


AF-0086 


AF-0090 


AF-0091 


Improve  Work  Organization 

AF-0025 

Improve  Job  Design 

AF-0026 

Evaluate  Job  Design 

AF-0076 

Evaluate  Work  Organization 

AF-0077 

lAF-0027 


AF-0028 


AF-0029 


AF-0018 


AF-0024 


AF-0030 


AF-0076 


AF-0087 


AF-0088 


AF-0089 


AF-0124 


AF-0125 


AF-0128 


AF-0129 


AF-0153 


AF-0031 


AF-0032 


E 


Build  Workforce  Well-Bein 


Build  Workforce  Satisfaction 


Assess  Member  Services 


Assess  Member  Facilities 


Assess  Member  Activities 


Assess  Member  Well-Bein 


Assess  Workforce  Satisfaction 


Assess  Workforce  Motivation 


Process  Management 


Design  Process 


Design  Service 


Implement  Process 


Project  Plannin 


Develop  Design  Criteria 


Develop  Software  Architecture  Design 


Develop  Software  Detail  Design 


Test  Product 


Test  Service 


Review  Product  _ 


Pilot  Process  Improvement 


Evaluate  Process 


Evaluate  Product 


Evaluate  Service 


Measure  Process  _ 


Determine  Root  Cause 


Analyze  Data 


Take  Corrective  Actions 


Evaluate  Alternatives 


Evaluate  Process 


Do  Research 


Implement  Process 


Develop  Design  Criteria 


Determine  Root  Cause 


Measure  Process 


Analyze  Data 


Take  Corrective  Actions 


Implement  Process 


Evaluate  Alternatives 


Evaluate  Process 


Do  Research 


AF-0033 


lAF-0034 


AF-0035 


AF-0036 


AF-0037 


AF-0023 


lAF-0090 


AF-0091 


AF-0038 


AF-0039 


AF-0040 


AF-0114 


AF-0153 


AF-0154 


AF-0155 


AF-0041 


AF-0042 


AF-0108 


AF-0186 


AF-0070 


AF-0092 


AF-0093 


AF-0072 


AF-0043 


AF-0073 


AF-0114 


AF-0116 


AF-0044 


AF-0070 


AF-0094 


AF-0187 


AF-0153 


AF-0043 


AF-0072 


AF-0073 


AF-0114 


AF-0116 


AF-0187 


AF-0044 


AF-0070 


AF-0094 
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5.4.a  _ Determine  Indicators _ AF-007 1 


Measure  Process  _  AF-0072 


Analyze  Data _ AF-0073 


Communicate  Supplier  Requirements _ AF-0095 


Determine  Key  Supplier  Requirements _ AF-0096 


Communicate  Information _ AF-0097 


Measure  Product  _ AF-0118 


Project  Review  _ AF-0148 


Build  Supplier  Relationship _ AF-0045 


Evaluate  Process _ AF-C)070 


Change  Supplier  Commitment _ AF-01 13 


Plan  Supplier  Work  _ AF-01 19 


Implement  Process  _ AF-01 87 


Performance  Results 


6.1.a _ Analyze  Data  _ AF-0073 


Gather  Internal  Data _ AF-0098 


Measure  Product  _ AF-0118 


6.2.a  Measure  Process  _ AF-0072 


Analyze  Data _  _ AF-0073 


Gather  Internal  Data  _ AF-0098 


6.3.a _ Measure  Process  _ AF-0072 


Analyze  Data  _ _ AF-0073 


Measure  Product  _ AF-0118 


Customer  Focus  and  Customer  Satisfaction 


7.1.a  Determine  Customer  Requirements _ AF-0046 


Determine  Customer  Expectations  _ AF-0047 


Determine  Indicators  _ AF-007 1 


Determine  Customer  Groups _ AF-0099 


[SiTit] 


Gather  Customer  Information _ AF-0101 


Determine  Future  Customer  Requirements _ AF-0048 


Determine  Future  Customer  Expectations _ AF-0049 


Develop  Listening  Strategies _ AF-0050 


Evaluate  Process _ AF-0070 


7.2.a  Communicate  Information _ AF-0097 


Provide  Customer  Access  _ AF-01 02 


Maintain  Service  Standards _ AF-01 03 


Maintain  Product  Standards  _ AF-01 04 


Gather  Customer  Feedback  Data _ AF-0105 


Analyze  Data _ AF-0073 


Gather  Customer  Information _ AF-0101 


Record  Customer  Complaint _ AF-01 06 


Evaluate  Customer  Complaint _ AF-01 07 


E-6 


7.2.C 

Evaluate  Mission  Effectiveness 

AF-0051 

Analyze  Data 

AF-0073 

7.2.d 

Evaluate  Process 

AF-0070 

7.3.a 

Evaluate  Mission  Effectiveness 

AF-0051 

Analyze  Data 

AF-0073 

Determine  Customer  Groups 

AF-0099 

Evaluate  Measurement  Scale 

AF-0052 

Improve  Measurement  Scale 

AF-0053 

Evaluate  Process 

AF-0070 

7.4.b 

Analyze  Data 

AF-0073 

7.5.a 

Analyze  Data 

AF-0073 

7.5.b 

Analyze  Data 

AF-0073 
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